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Preface 


The  purpose  of  this  study  is  two  fold.  The  first 
purpose  is  to  design  a  data  base  management  system  model  for 
the  organization  structure  of  the  Egyptian  Armed  Force  as  a 
part  of  the  integrated  information  system.  The  second 
purpose  is  to  implement  that  model  as  an  applicable  system 
ready  to  serve  in  the  Egyptian  Armed  Force. 
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encouragement  that  I  received  from  my  thesis  advisor  Dr. 
Henry  Potoczny  and  from  the  committee  members.  Dr.  Thomas 
Hartrum,  Lt.  Col.  Richard  Gross  and  Ma j .  John  Stibravy. 

Finally,  I  would  like  to  thank  my  wife,  Nagwa,  and  the 
rest  of  my  family,  for  their  constant  understanding, 
support,  and  encouragement  without  which  I  could  not  have 
finished  this  work. 
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Abstract 

The  organization  structure  system  is  a  part  of  the 
integrated  information  system  of  the  Eygptian  Armed  Forces. 
It  manipulates  the  units  organization  data  (department,  unit 
level,  type,  balance,  armament,  personnel,  plan(s),  per¬ 
centage  of  completeness ,  location  and  position  in  the  armed 
force  tree).  An  initial  survey  for  the  problem  is  done. 

The  design  of  the  system  is  done  through  the  E-R  model  and 
the  functional  dependency  is  defined.  We  choose  the  rela¬ 
tional  data  base  model  for  its  advantages  like  data 
independent  and  simple  data  manipulation,  over  the  other  two 
DBMS  models  ( h  i  -■>  rarch  ical  and  network  models).  The  system 
is  designed  in  ten  relations  and  the  implementation  is  done 
tnrough  ingress  using  C  programming  language  with  equal 

\  r  ■  ’ 

(embedded  ingres  in  C).  We  preae..  aysevera  1  examples  of 
queries  that  the  system  can  support.  An  algorithm  for 
collecting  the  units  commanded  by  i  particular  unit  is 
presented.  The  implementation  includes  the  data  definition 
of  the  ten  relations  in  ingres.  The  data  base  editing 
program  is  presented  which  consists  of  23  modules.  This 
program  is  abl'-  to  perform  the  addition,  modi  f  ica  t  ion , 
deletion,  and  retrieval  of  units  data  keeping  the  data  base 
in  consistent  state.  The  problems  of  recovery,  concurrency, 


DESIGN  AND  IMPLEMENTATION  OF  DATA  BASE  MANAGEMENT 
SYSTEM  FOR  THE  ORGANIZATION  STRUCTURE  OF  THE 
EGYPTIAN  ARMED  FORCES 

I .  Introduction 

Background 

In  Egypt  it's  highly  recommended  that  a  national  inte¬ 
grated  information  system  be  built.  The  Information  System 
Department  did  a  lot  of  work  in  the  analysis  and  the  design 
phase  of  the  integrated  information  system.  Building  the 
integrated  information  system  for  the  Egyptian  Armed  Force 
is  very  essential.  This  integrated  system  will  support  the 
dynamic  decision  making  process  in  all  military  areas.  There 
is  a  lot  of  w">rk  done  in  the  area  of  investigation  and 
analysis  of  tin-  integrated  information  system.  There  are 
many  appliea-  .  ns  implemented  as  file  system  projects,  but 
there's  no  application  designed  in  data  base  management 
system  yet. 

Problem 

Th-'  purpose  of  this  th-sis  effort  ’  to  design  and 
i  [dement  a  data  base  management  system  for  the  organization 
s  1  ture  of  the  Egyptian  Armed  Forces  as  a  subsystem  of  the 
integrated  information  sy.  keeping  in  consideration  da* 

b  i . .  ’  integrity  and  system  interfaces  to  other  systems/ 


Scope 

The  scope  of  this  effort  was  limited  to  the  design  and 
implementation  of  a  prototype  data  base  management  system 
for  the  organization  structure  of  the  Egyptian  Armed 
Forces.  This  newly  designed  system  is  able  to  answer  any 
query  related  to  the  organization  structure  data.  An 
Editing  Program  for  the  unit  data  is  implemented. 

Approach 

The  approach  for  this  project  follows: 

1.  General  study  of  the  Egyptian  Armed  Forces 
structure . 

2.  Description  of  the  integrated  information 
system . 

3.  Design  of  entity  relationship  model  for  the 
new  designed  system. 

4.  Choice  of  data  base  management  system  model. 

5.  Design  of  logical  data  base. 

6.  Physical  data  base  representation. 

7.  Design  and  implementation  of  the  editing 
p '  >‘.j  l  d  m  • 

Discussion  about  the  system  related  problems 
(recovery,  concurrency,  security,  integrity, 
an:  system  interfaces). 
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Introduction 


The  Egyptian  Armed  Force  formation  consists  of  six  main 
entities : 

1.  Arms  and  Equipments 

2  Manpower 

3.  Unit  Formation 

4.  Supply 

5.  Facilities 

6.  Transportation 

Actually  no  single  entity  can  stand  by  itself. 

To  get  the  system  to  work,  we  must  assign  the  suitable 
arms  and  equipment  with  a  well  trained  manpower  to  a  suit¬ 
able,  well  organized  unit,  and  secure  supplies,  facilities, 
and  transportation.  That  lets  a  single  unit  work  in 
reasonable  efficiency.  But  our  goal  is  to  let  the  whole 
armed  force  work  in  harmony  with  high  efficiency  and 
effectiveness  in  both  war  and  peace  time. 

No  doubt,  the  only  way  to  reach  the  required  degree  of 
efficiency  of  the  armed  force  that  is  equipped  with  a 
modern  arms  and  equipment  is  through  an  integrated 
information  system. 

Developing  a  computerized  national  information  system  in 


Egypt  is  under  investigation.  The  Egyptian  Armed  Force  is 


the  leader  in  that  field.  The  Ministry  of  Defense  (MOD)  is 
always  eager  to  help  other  ministries  build  their  own 
computerized  information  system. 

Before  attempting  to  design  the  computer  system  we  will 
make  a  brief  description  of  the  Egyptian  Armed  Force  from 
the  point  of  view  of  the  six  main  entities  mentioned  above. 

Description  of  Egyptian  Armed  Forces 

The  Egyptian  Armed  Forces  consists  of  five  main 
branches : 

1 .  Army 

2 .  Navy 

3.  Air  Force 

4.  Air  Defense 

5.  Border  Guard 

Actually  each  branch  may  operate  independently  and  has  its 
own  command.  In  the  Army,  each  field  army,  or  military 
area,  has  its  own  command  and  its  own  budget,  but  it  is  not 
completely  independent.  For  example,  logistic  supun.t  is 
centralized  for  the  whole  armed  force;  also,  personnel 
supplies  with  draftees  is  centralized  (it  is  permitted  to 
let  the  enlisted  person  join  the  branch  of  his  choice). 

The  description  of  the  Egyptian  Armed  Force  will  focus  on 


the  six  main  entities: 


1. 

Arms  and  Equipment 

2. 

Manpower 

3. 

Unit  Formation 

4. 

Supply 

5. 

Facilities 

6. 

Transportation 

Arms  and  Equipments  (A  &  E) 

The  Egyptian  Armed  Force  has  a  wide  variety  of  arms  and 
equipment  that  maybe  classified  into  four  main  categories: 

1.  U.  S.  A  &  E 

2.  Eastern  A  &  E 

3.  European  A  &  E 

4.  Egyptian  A  &  E 

The  different  sources  of  A  &  E  create  difficulties  in 
classification  and  codification  processes  for  the  arms  and 
equipment  (complete  set  and  parts).  Several  studies  were 
done  on  the  existing  inventory  systems,  supply  systems,  and 
technical  support  system. 

The  studies  yield  a  decision  taken  by  the  Egyptian 
Ministry  of  Defense  (MOD)  to  use  the  NATO  system  of  classi¬ 
fication  and  codification  for  complete  arms  and  equipment 
and  parts  as  the  primary  base  of  the  new  Egyptian  com¬ 
puterized  inventory  system  (as  a  subsystem  of  the  logistic 
support  system).  To  show  th*>  variety  of  A  &  E,  the 
following  are  the  types  of  arms  used  by  the  Egyptian  armor 
and  a-'  illery  as  estimated  in  the  Air  Force  Ma.anine, 
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Main  Fighting  Tanks 

T-54,  T-55,  T-62,  AM-60 (M-60  A3),  PT-76 

Armored  Fighting  Vehicles 

BRDM-1,  BRDM-2 ,  Scout  ARS,  BMP-1,  PMP-600P 
Vehicles,  OT-62,  Walid,FAhd,  BTR-40,  BTR-50,  BTR-60 
armor  carriers,  M  113  A2  armored  carrier. 

Artillery 

Guns:  85  mm,  M-1955,  SU100-100  mm,  D-30, 

M-46-130  mm,  SU-152,  S-23,  180  mm. 

Howitzers:  M-1938  122  mm,  M-1943  192  mm. 

Mortars:  120  mm,  160  mm,  240  mm. 

Multi-Rocket  launchers 

122  mm,  132  mm,  140  mm,  240  mm. 

Surface  to  Surface  Missiles 

Frog-7,  Scud-B 

Anti-Tank 

Recoiless  Launchers:  57  mm,  76  mm,  100  mm 
Bll-107  mm 

Guided  Weapons 

Sagger,  Snapper,  Swatter,  Milan,  Beeswing, 
Swing  fire,  'i\.w 


K: 


I  ^ 

‘>3  >V 


Air  Defense 


Self  Propelled 
Surface  to  Air 
Skyguard  (6:122) 


Aircraft  Guns: 
Missile:  SA-6, 


ZS  U-23-4, 
SA-7,  SA-9, 


,  Compat 
,  BTR-152 

122  mm. 


,  82  mm. 


ZS  U-57-Z 
Carstal , 
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(This  is  not  included  in  Air  Defense  Command) 

From  these  arms,  we  can  find  the  eastern  arms  like  the 
T-62  tank,  the  U.S.  arms  like  the  M-60  tank,  the  European 
arms  like  Crotal  Air  Defense  System,  and  the  Egyptian  arms 
like  Walid  armored  vehicle. 

For  all  the  A  &  E,  we  need  a  classification  that  can 
meet  the  requirements  of  the  new  designed  system.  This  will 
be  discussed  later. 


Manpower 


The  manpower  may  be  divided  into  three  main  categories: 


a.  Professionals: 


That  includes  active  duty  officers,  non 
commissioned  officers,  and  civilians  who  are  working  for  the 
Armed  Forces. 


b.  Draftees: 


Th--'  draftees  are  men  recruited  to  serve  in  the 
armed  for  •  a  mandatory  service  for  a  certain  period  of 
time.  Four  years  for  education  below  high  school,  three 
years  for  high  school  graduates  and  one  year  for  education 
higher  than  high  school.  That  is  three  years’  average.  The 
draftees  re  ruited  as  soldiers,  excer 1  for  the  draftees  who 
have  education  higher  than  high  school,  may  be  recruited  as 
officers.  In  this  case,  they  must  stay  two  years  1  the 
service . 
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Reserve : 


c . 

All  draftees  must  stay  in  the  reserve  service  a 
certain  period  of  time.  The  reserve  man  may  be  reassigned 
to  the  same  unit  he  was  serving  in,  or  to  another  unit.  The 
reserve  is  mobilized  periodically  for  training. 

Another  classification  of  manpower  which  is  mainly  used 
for  planning  and  for  unit  establishment  tables  is: 

a .  Officer : 

This  includes  all  types  of  officers  whatever 
their  ranks,  specializations,  type  of  service. 

b .  Secretary : 

This  includes  all  military  personnel  who  are 
working  in  jobs  like  clerk,  administration,  finance,  typing, 
document  handling,  librarians,  bookkeeping,  etc. 

c .  Commissions : 

This  includes  all  military  personnel  whose  jobs 
are  to  operate  i:.  an  arm  or  equipment  except  for  driving  and 
technical  maintenance,  and  also  includes  military  drill 
per sonne 1 . 

d .  Driver : 

This  includes  all  types  of  drivers:  truck  driv¬ 
ers,  tank  drivers,  clerk  drivers,  bulldozer  drivers,  etc. 

e .  Technician : 

This  includes  all  military  personnel  whose  work  is 
in  technical  maintenance,  technical  inspection,  and  also 
per  ;  • 1  who  work  in  technical  training  jobs. 


f.  Craftees: 


This  includes  all  craft  jobs  like  tailors, 
carpenters,  painters,  operators,  etc. 

Unit  Formation. 

There  are  different  types  of  units  in  the  Egyptian  Armed 
Forces.  The  classif ication  of  the  unit  types  is  done 
according  to  the  main  mission  and  level  of  command.  The 
unit  name  and  class  does  not  necessarily  reflect  its  level 
of  command.  For  example,  one  company  may  be  commanded 
directly  by  a  field  army  command,  another  is  related  to 
battalion  then  brigade,  then  division,  then  to  a  field  army 
command.  The  following  is  a  brief  description  of  the  unit 
main  types: 

Ministry  of  Defense  (MOD) . 

This  is  the  highest  command  level  in  the  Egyptian 
Armed  For  ■  s  and  it  commands  all  other  uni * 

Main  Branc hes . 

There  are  five  main  branches  (army,  navy,  air 
force,  air  defense,  and  border  guards).  Each  branch  has  a 
single  co  .and.  Except  for  the  army,  there  is  a  single 
command  ■  each  field  army  or  military  area.  The  main 
branch  is  commanded  directly  by  the  MOD. 

Field  Armi-'-s  and  Military  Areas. 


Each  field  army  or  military  area  is  a  complete 
format  l  of  army  units.  (There  may  be  some  Air  Defense 


units  included  in  the  formation  established  for  a  certain 


/«£*• 
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mission(s)).  A  field  army  or  military  area  is  commanded 
directly  by  the  MOD. 

Authorities . 

Each  authority  is  completely  responsible  for  a  main 
mission(s)  in  the  armed  forces.  For  example,  the  training 
authority  is  responsible  for  planning  and  follow-up  of  all 
types  of  training  in  the  armed  forces  starting  from  primary 
military  drill  to  the  specialized  training  and  graduate 
programs  needed.  The  logistic  authority  is  completely 
responsible  for  all  logistic  affairs  for  all  armed  forces. 
The  authorities  are  commanded  directly  by  MOD. 

Centralized  Departments. 

Each  centalized  department  represents  a  branch  of 
service  for  the  military  personne1  and  commanded  directly  by 
MOD.  Infantry  departments,  armor  departments,  signal  corp 
departments,  are  examples  of  the  centralized  dejai tments. 
Each  specialized  department  is  responsible  for  supplying  the 
armed  force  units  and  formations  with  personnel.  For 
example,  the  armor  department  is  res^  -risible  for  supplying 
the  arm-.:  force  units  and  format  i.-.n  with  armor  personnel 
according  to  each  unit  establishment  table  and  percentage  of 
completeness  (this  will  be  discu  .  later). 

Each  centralized  department  is  responsible  for 
supporting  reviewing,  and  inspecting  of  the  unit  of  the 
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same  branch  of  service.  For  example,  the  infantry  depart¬ 
ment  is  responsible  for  completeness  of  all  personnel  in  all 
infantry  units.  That  means  it  should  know  the  requirements 
of  each  unit  from  each  branch  of  service  to  reach  the  re¬ 
quired  efficiency.  In  other  words,  the  infantry  department 
should  know  types  and  quantities  of  personnel  needed  from 
the  infantry  department  and  from  other  departments  to  com¬ 
plete  an  infantry  unit  according  to  its  establishment  table 
and  percentage  of  completeness.  Some  specialized  depart¬ 
ments  are  completely  responsible  to  supply  arms  and 
equipment  related  to  the  same  branch  of  service,  some  are 
not . 

For  example,  the  armor  department  is  responsible 
for  supply,  technical  support,  training  personnel,  and 
inspect  ion  of  all  armor  equipment  in  armor  units  and  also 
other  unit:-.  On  the  o’- her  hand,  the  infantry  department  is 
not  responsible  for  technical  support  of  infantry  weapon... 

A  good  example  of  showing  how  the  centralized  departments 
cooperate  to  support  one  formation  is  a  mechanized  infantry 
brigade . 

The  infantry  department  is  the  sponsor  of  the 
mechanized  inf  ir’-ry  brigade  and  should  help  it  get  its 
needs  from  other  departments.  For  example,  the  infantry 
h  ■partm-'  •  provides  it  with  personnel  only.  The  armor 
:  :par tine rp  provides  it  vm  vh  armo.  carriers,  technical 


equipment,  and  parts  needed  for  its  operation.  The  armor 
department  is  also  providing  it  with  armor  drivers  and  with 
technical  support  personnel.  The  brigade  also  contains  a 
tank  bcttalion  (armor  unit).  The  fuel  department  provides 
the  brigade  with  the  needed  fuel  and  oil  and  also  personnel 
needed  for  handling  and  storing  that  fuel.  The  engineering 
department  provides  the  brigade  with  engineering  equipment 
and  personnel.  The  air  defense  command  provides  the  brigade 
with  complete  air  defence  battalion  (only  personnel).  The 
arms  and  ammunition  department  provides  the  brigade  with  all 
needed  types  of  arms  and  ammunition  and  related  equipment, 
and  also  provides  it  with  personnel  needed  for  handling  and 
technical  maintenance  of  arms  and  ammunitions.  Also,  other 
departments  like  the  signal  corp,  chemical,  artillery, 
electronic  warfare,  food,  clothing,  etc.  provide  the  brigade 
with  different  needs.  From  the  above  example,  we  can 
recognize  that  there  are  many  departments  that  are 
responsible  for  providing  each  army  unit  with  its  needs.  To 
keep  the  units  and  the  formations  free  from  contacting  all 
departments,  there  is  a  sponsor  department  for  each  unit  and 
formation  that  should  do  what  is  necessary  to  let  the  unit 
or  the  formation  reach  the  required  degree  of  completeness. 

Non  Centralized  Departments. 


The  clothing  department  represents  a  branch  of 
service  but  is  commanded  by  the  logistic  authority.  The 


information  systems  department  is  commanded  by  MOD  but  does 
not  represent  a  branch  of  service.  The  recruiting 
department  is  commanded  directly  by  organization  and 
management  authority  and  does  not  represent  a  branch  of 
service.  A  non  centralized  department  maybe  a  sponsor  of  a 
certain  type  of  unit. 

Formation  Units . 

In  the  army,  formation  units  start  from  the  field 
army,  division,  brigade,  battalion,  company,  platoon,  and 
team.  In  the  air  force  it  starts  from  air  base,  air 
brigade,  air  port,  and  squadron. 

Other  types  of  units  such  as  workshop,  depot, 
store,  wea*;:.  r  station,  etc.,  should  be  considered  also. 

Supp 1 y . 

There  are  three  main  types  of  supplies: 

-  Arms  and  equipment  supplies. 

-  Personnel  supplies. 

-  Consumer  material  r.upo'  ’  as . 

A  r  and  Equipment  Supplies  . 

Arms  and  equipment  supply  is  done  in  both  peace  and 

wir  t  i !iv  ;  >r  several  ron  •"'•ns : 


-  New  unit  establishment. 

-  Replacement  of  damaged  or  destroyed  equipment. 

-  Replacement  plan  by  another  type  of  arm/ 

equipment . 

-  Completion  of  units. 

Personnel  Supplies. 

As  the  units  do  not  have  to  be  completed  100% 
during  peace  time,  personnel  supply  with  the  needed 
specialization  of  personnel  will  function  during  peace  time 
for  different  reasons: 

-  New  estab1 ished  unit. 

-  Military  service  termination. 

-  Change  of  percentage  of  recompletion  of  the 

unit. 

-  Declaration  of  general  mobilization. 

-  Recompletion  of  units  durinj  war. 

The  personnel  supply  is  done  during  war  with 
reserve  or  with  active  duty  personnel  (if  available). 

Co  .  u.ner  Material  Supplies  . 

This  type  of  supply  includes  all  types  of  materials 
needed  for  the  unit  to  fulfill  its  mission  successfully. 

That  incl  :i^s  ammunition,  food,  clothes,  fuel  a  •  1  lubricant, 
medical  supply,  parts,  and  other  needed  materials. 

Faci 1  it i . 


This  ir-'udes  planning,  maintenance  and  inspection  for 
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all  needed  facilities  to  the  armed  force  units.  Some 
civilian  constructions  and  facilities  may  be  mobilized 
during  war  time  according  to  facilities'  mobilization  plan. 
For  example,  some  civilian  hospitals  may  be  dedicated  to  the 
military,  some  civilian  factories  and  workshops  maybe 
dedicated  to  the  military  also. 

Transportation. 

This  includes  transportation  of  material,  personnel,  and 
supplies  to  and  from  military  units  during  peace  and  war 
time.  This  may  be  done  by  the  unit  and  formation  trans¬ 
portation  means  or  by  other  means  according  to  the 
transportat ion  plan. 


In  that  sense,  the  logistic  support  system  should 
include  the  elements  of  planning,  acquisition,  maintenance, 
test  and  support  equipment,  supply  support,  transportation 
and  handling,  personnel  management,  and  all  needed 
management  and  technical  data.  The  main  purpose  of  the 
logistic  supply  system  is  to  supply  personnel,  material, 
facilities  and  technical  support  to  the  armed  force  units 
and  formations  at  the  right  time  with  the  right  quantity. 

The  management  of  the  organization  structure  of  the 
armed  force  is  one  of  the  most  important  activities  in  the 
logistic  support  system.  That  is  the  maintenance  and 
support  of  the  organization  structure  of  the  armed  force 
according  to  the  national  defense  plan  and  available  defense 
budget . 

The  integrated  logistic  support  system  will  contain  four 
main  systems: 

-  Personnel  Systems 

-  Organization  Structure  System 

-  Material  Support  System 

-  Finance  System 

Personnel  Management  System . 


The  personnel  system  should  manage  the  information  about 


.u  j* 'ju  ,«*  _4i  .k  -<»•'  Ji  .»<  .’2  >  j  mii  .■■  t  ^ a' »  i'ia~tj,l  .>i->'».i  »  i  |  •  k»,Li  a.^  kf  »  at- !»*.  |L  #•*.  »*>-*t-I 


-  Officers 


-  Enlisted  Personnel 


-  Draftees 


-  Reserve 


-  Civilians 


There  is  not  a  big  difference  between  the  design  and  the 


needed  information  for  both  officers  and  enlisted 


sub-system,  because  both  are  professionals  and  usually  spend 


most  of  their  productive  life  in  the  military  service.  Both 


sub-systems  should  keep  track  of  all  necessary  information 


needed  for  promotion  plan,  reassignment  plan,  training  plan, 


and  retirement  plan  besides  necessary  personnel  records. 


The  recruiting  sub-system  is  not  so  simple.  It  should  keep 


track  of  the  personal  information  during  three  phases  of  the 


person's  life: 


-  Before  military  service  as  a  civilian 


-  During  military  service  as  a  draftee 


-  After  military  service  as  a  reserve 


Before  Military  Service. 


Every  Egyptian  male  mu^i  have  an  ID  card  at  the  age 


of  16  year ^  old  by  the  law.  The  personnel  data  are 


transferred  from  the  civil  recording  offices  to  the 


recruiting  department  which  i.  :intain  that  record  and  amends 


it  if  necessary  according  to  education  and  health  records. 


This  data  will  be  processed  to  prepare  the  recruiting  plan 


according  to  the  armed  force's  needs 


IV  |«»  VV 'lOAi 


During  the  Military  Service. 


The  system  should  be  able  to  select  personnel  to 


certain  jobs  in  certain  departments  according  to  the  needs 


of  the  armed  force  units.  The  training  plan  for  the 


draftees  should  be  done  for  each  department.  Because  there 


is  a  different  training  period  needed  for  each  type  of 


personnel  specification,  the  system  should  be  able  to  keep 


track  of  that  information  and  prepare  the  assignment  plan. 


then  follow  up  the  execution  of  this  plan. 


The  system  should  keep  track  of  the  personnel 


records  during  the  military  service  (promotion,  new 


assignment,  punishments,  etc.).  The  military  service 


termination  plan  should  be  prepared  according  to  the 


regulation  stated  by  the  law. 


After  the  Military  Service. 


Ev-_ry  draftee  must  stay  a  certain  period  of  time  in 


the  reserve  according  to  the  law,  except  some  special  cases 


stated  by  the  law.  The  person  should  know  the  newly 


assigned  unit  in  the  reserve  service  (usually  it  will  be  the 


same  uric)  and  how  to  reach  it. 


The  mobilization  may  be  done  for  training  purposes 


or  for  war.  The  system  should  be  able  to  keep  track  of  all 


reserve  information  and  prepare  mobilization  plan  for  both 


me  and  war  time  and  also  follow-up  its  execution. 


The  civilian  sub-system  is  a  typical  personnel 
system.  It  should  keep  track  of  personnel  records,  prepare 
reassignment,  promotion,  and  retirement  plans.  The  system 
also  should  estimate  the  real  needs  from  the  civilian 
specif ications . 

Management  of  the  Organization  Structure  of  the  Eyptian 
Armed  Forces 

Establishment  of  a  military  unit  is  done  through  an 
organized  process  according  to  the  real  needs  of  the  armed 
force  to  fulfill  the  national  defense  plan,  putting  in 
consideration  the  availability  of  the  following: 

1.  Arms  and  Equipments 

2.  Manpower 

3.  Facilities 

4.  Supply 

5.  Budget 

The  unit  is  considered  to  be  established  as  soon  as  its 
organization  instruction  is  issued.  The  organization 
instruction  is  regarded  as  the  "birth  certificate"  of  the 
unit.  A  copy  is  sent  to  main  ;  ra r. .1, _  and  departments. 

Each  organization  instruction  has  a  unique  serial 
number.  "my  units  may  be  established  by  the  same  organ¬ 
ization  instruction.  Any  change  in  the  unit  establishment 
data  must  be  done  through  another  organization  instruction. 


The  organization  instruction  specifies  the  sponsor  depart¬ 
ment  and  lists  the  departments  responsible  for  supplying  the 
newly  established  unit  with  personnel,  arms,  equipment,  and 
facilities. 

Each  department  mentioned  in  the  organization 
instruction  must  assign  the  necessary  personnel,  arms, 
equipment,  and/or  facilities  by  the  due  dates  stated  in  the 
instructions.  The  organization  instruction  should  contain 
the  following  information: 

1.  General  description  of  the  unit 

2.  Description  of  the  unit  internal  structure 

3.  Description  of  logistic  support 

4.  Full  description  of  personnel  needed  for  the 
unit  establishment  according  to  the  unit 
internal  structure  (this  is  summarized  in  the 
organization  table) . 

5.  Full  description  of  arms  and  equipments  needed 
for  the  unit  established  according  to  the  unit 
internal  structure  (summarized  in  the  armament 
table) . 

6.  Timetable  for  establishment  phases. 

The  following  unit  data  must  be  stated  in  the 

organization  instruction: 

1.  Unit  name  -  unique  name  to  identify  the  unit. 

2.  Main  branch  -  army,  navy,  air  force,  air 
defense,  or  border  guard. 

3.  Sponsor  department  -  armor,  signal  corp, 
artillery,  etc. 

4.  Unit  level  -  division,  brigade,  battalion, 
etc . 


Unit  type  -  This  attribute  (with  department  and 
unit  level)  identifies  the  unit  type.  For 
example,  if  (3)  and  (4)  describe  an  infantry 
battallion,  (5)  will  describe  the  infantry 
battalion  as  mechanized  infantry  battalion 
or  airborn  infantry  battalion  or  other  type 
of  infantry  battalion. 

Unit  number  -  this  number  is  a  unique  number 
with  respect  to  each  unit  type  to  differentiate 
between  different  units  of  the  same  type. 

Percentage  of  Completeness  -  According  to  the 
primary  mission  of  the  unit,  the  percentage  of 
completeness  of  personnel  may  be  identified  to 
be  less  than  or  equal  to  100%.  The  unit  may  be 
completed  by  mobilization  for  training  reasons 
or  for  war  reasons.  New  units  are  established 
according  to  the  available  arms  and  equipment. 
For  tactical  reasons,  arms  and  equipment  should 
be  completed  even  if  the  completeness  of 
personnel  is  less  than  100%. 

This  attribute  describes  the  unit's  main  missio 
from  the  point  of  view  of  armed  force  general 
balance.  It  may  be  one  of  the  following  six 
types : 

a.  Command  and  control  (e.g.)  signal  cnrp 
units. 

b.  Fight'-  ;  (e.g.)  infantry  or  tank  battalion 

c.  Fighting  assistance  (e.g.)  engineering 
battalion. 

d.  Logistic  (e.g.)  transportation  battalion. 

e.  Technical  (e.n.)  armor  field  work... hop. 

f.  Training  (e.g.)  artillery  school. 

Location  -  The  organizational  instruction  must 
identify  the  primary  unit  location.  Egypt  is 
divided  into  six  main  military  location  areas. 

Command  Unit  -  Each  unit  must  h--*  commanded  by 
only  one  unit  (except  th--*  Mon  -  timt  is 
regarded  as  the  root  or  th*-  armed  forces 


11.  Commanded  Sub  Unit (s)  -  The  organization 
structure  should  state  other  units  commanded  by 
the  established  unit  (if  any). 

12.  Defense  Plan  -  This  attribute  defines  which 
defense  plan  this  unit  has  a  mission.  The  unit 
may  be  assigned  to  more  than  one  plan. 

13.  Personnel  Table  -  This  table  summarizes  the 
required  personnel  for  different  departments 
according  to  the  five  main  specifications. 
Figure  2  illustrates  an  example  of  a  personnel 
table . 

14.  Armament  Table  -  This  table  specifies  the 
required  arms  and  equipment  needed  for  the  unit 
(types  and  quantities).  The  department  that  is 
to  supply  that  type  of  equipment  may  not  be 
stated . 

The  armed  force  instructions  define  which  departments 
supply  which  arms/equipment.  In  some  cases,  the  department 
may  be  stated  to  eliminate  ambiguity  if  necessary.  Figure  3 
illustrates  an  example  of  an  armament  table.  Notice  that 
only  the  and  equipment  are  listed  in  the  table. 

If  the  newly  established  unit  has  the  same  organization  as 
an  existing  unit,  the  organization  instruction  refers  the 
organization  instruction  number  of  the  exi.  ■  Lng  unit  and 
both  o'-g  v.-.ization  and  armament  table  may  not  be  repeated. 

User  jjJs  from  the  Organization  Structure  Information 


System. 


1.  Keep  track  of  the  14  a1  tributes  mentioned  in  the 
organization  instruction  for  each  unit. 

2.  D-'H.ne  the  relations  between  the  different  types  of 
units. 


Create  the  hierarchical  information  model  for  the 
armed  force  units. 


Type 

Dep . 

Officer 

Secretary 

Commission 

Driver 

— 

Technician 

Craf tee 

Total 

Infantry 

16 

4 

320 

i 

341 

Armor 

1 

25 

6 

32 

Signal 

Corp 

1 

7 

2 

10 

Chemical 

WF 

1 

4 

5 

Wheeled 

Veh. 

12 

12 

Reconnais¬ 

sance 

1 

6 

7 

Medical 

Corp. 

1 

4 

5 

Total 

21 

4 

337 

41 

8 

i 

412 

Figure  2.  Personnel  Table  for  a  Mechanized 
Infantry  Battalion  (Example) 


Sma 1 1  Arms 


9  imn  pistol  64 

Automatic  gun  336 

Machine  Gun  9 

RB  J-7  9 

Artil lery 

82  mm  mortar  4 

Guided  anti  tank  missile  (tow)  6 

Anti  Air  Craft  Guided  Missile  (SAM-7)  3 

Armored  Carrier 

M  113  -  A2  24 

M  113  -  Recovery  1 

Wheeled  Vehicles 

4x4  Jeep  1/2  Ton  6 

4x4  Truck  1  1/2  Ton  2 

4x4  Truck  5  Tons  10 

Fu  - • !  Truck  2 

Wih  ''ruck  1 

A ;■  ;..ce  2 

Muifoeriance  Truck  (Armor  Dept.)  1 

Other  Equipment 

Generator  10  kw  1 

Wireless  Set  R124  4 

Wi re  1  e s So  t  R 1 2 7  1 


Figur  ■  3.  Armament  Table  for  a  Mechanized 
Infantry  Battalion  (i, /.ample) 


4.  Be  able  to  answer  queries  like: 

a.  Describe  the  organization  tree  for  the  10th 
Armor  Division  and  total  number  of  personnel 
for  each  unit  in  the  tree  and  for  the  division. 

b.  Identify  the  types  and  number  of  personnel 
needed  from  the  signal  corp  department  to 
supply  the  units  sponsored  by  the  armor 
department . 

c.  Identify  the  personnel  requirement  to  the 
fifth  field  army  by  type  and  number  from 
the  specialized  departments. 

d.  How  many  Howitzer  160  mm  or  240  mm  should 
exist  in  the  west  location? 


e.  What  armor  unit  exists  in  Central  location 
to  support  plan  A? 

5.  Identify  and  secure  the  interface  between  the  system 
and  the  other  systems  (personnel,  finance,  and 
material  support)  and  with  command  and  control 
system. 

Material  Support  System 

This  system  should  perform  the  procuring,  maintaining, 
and  securing  of  the  following: 

1.  Complete  Arms  and  Equipment 

2.  Spare  Parts 

3.  Daily  Consumed  Material  (food,  fuel,  clothes, 

medical  support,  etc.). 

4 .  Ammun i t  ion 

5 .  Faci 1 ities 

6.  Transportation 

7.  0*-h<*r  Military  Material 

This  ...tern  deals  w;‘'_i  a  wide  variety  of  military 
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material.  But  fortunately,  most  of  it  is  related.  For 
example,  one  of  the  system's  main  jobs  is  related  to  the 
military  arms  and  equipments.  The  operation  of  A  &  E  needs 
ammunition  and  fuel,  the  technical  support  of  A  &  E  needs 
parts  and  lubricants  and  both  of  them  need  transportation, 
so  most  of  the  data  related  to  the  A  &  E  is  still  in  the 
same  system.  On  the  other  hand,  the  system  still  needs  some 
information  from  the  organization  structure  system  about 
unit  structure,  location,  and  armament  table  for  each  unit. 

Another  type  of  information  needed  from  the  command  and 
control  system  is  the  operational  mission  for  units  to  be 
able  to  secure  suitable  amounts  of  ammunitions,  fuel, 
transportation,  food,  and  water,  procurement  and  maintenance 
of  the  material.  This  needs  complete  interaction  with  the 
finance  ->m. 


Finance  System 

No  one  can  ignore  the  impact  of  the  financial  matter  on 
all  s-g^onts  of  the  armed  forces.  Armament,  personnel, 
sut. ;  ,  and  facilities  are  examples  of  th-w;e  segments  that 

are  highly  affected  by  financial  decisions. 

The  function  of  the  finance  system  is  defined  by  Herbert 
T  .  S  p  i  r  a  a  x  : 

Finance  engages  in  two  ;  irnary  types  of 
functions  for  top  manajj.  -nt  :  recording, 
monitoring,  and  controlling  of  financial 
consequences  of  past  and  current  operations, 
and  -ring  funds  to  meet  curren*  a  .  ! 

fu‘  -  .  coeds.  ( S 


To  accomplish  the  first  set  of  functions,  the  finance 
system  needs  well-defined  interface  with  material  support, 
personnel,  organization  structure  and  command  and  control 
systems.  The  second  set  of  functions  needs  interfacing  with 
outside  institutions  (e.g.,  Ministry  of  Treasury,  Ministry 
of  National  Planning,  etc.).  Discussion  of  the  finance 
system  is  out  of  the  scope  of  this  project. 

Command  and  Control  System 

To  describe  the  system  of  Command  and  Control  (C^) , 
note  Dr.  Robert  E.  Conley's  definition: 

Command  and  Control  ( C 2 )  is  a  process 
of  resource  allocation  (management)  by 
a  knowledgeable,  recognized  point  of 
authority  to  accomplish  a  giver: 
oo  j  •  -  c  t  ive  .  (3:16) 

■) 

inis  dei  ,  n  it  ion  describe.;  the  C  “  sy  as  th-'  process 

by  which  th-1  .blitary  object,. e(s)  may  be  accompl  ished  w:  *h 
to  e f t  l 1  a  o 1 e  resources.  Ac*  rally,  the  definition  is 
applicable  for  military  and  other  management  areas  and  the 
authority  may  rot  be  a  human.  The  C^  system  cannot 
t  r.  Tease  the  f  .ource  e-,p.->bi  1  ity  bnr  .  .  ;  t  a  1  1  :  . 

the  r- 'Source  n  ‘  app.  ipr  i  it*1  t  i  me  e:  :  ■>.  u 

era  1 izat ion  of  the  C^  system  results  in  c  '  ,  "command , 
control,  com, nun  ica f  ion  and  i  r.te  1  1  ig-cnce"  sy,  1  ■  given  a 

scope  of  rmation  that  should  be  collec--  :  an  '  :  ,  •••  ,sed 

tic  t  h  .•  system.  Two  cat  :  ri-s  of  inf  cc  b  ion  shot.  ’  i  be 


manipulated  by  the  system;  our  own  forces  and  the  opposing 


forces.  Types  of  information  and  functions  of  the  C2 

system  are  described  by  the  official  definition  of  command 

and  control  in  the  Joint  Chief  of  Staff  (JCS)  Dictionary  a 

The  exercise  of  authority  and  direction  by 
a  properly  designated  commander  over  assigned 
forces  in  the  accomplishment  of  his  mission. 
Command  and  Control  functions  are  performed 
through  an  arrangement  of  personnel,  equip¬ 
ment,  communication,  facilities,  and  procedures 
wnich  are  employed  by  a  commander  in  planning, 
directing,  coordinating,  and  controlling  forces 
and  operations  in  the  accompl i shment  of  his 
mission.  (3:26) 

T.ne  components  of  the  C2  system  are  defined  by  J.  S. 
Lawson  as: 

1  .  Sensors 

2.  Communications 

3.  Data  Processing 

4  .  Information  M  a  n  a  g  •?  x  <  •  r.  t 

5.  Decision  AiJs 

6.  Forces  to  Command 

7.  A  Commander  (3:62) 

A  basic  model  of  C2  proc-s 


is  described  in  Figure  4 


Figure  4. 


Basic  Model  of 


Process 


Scope  of  the  Project 

From  the  previous  discussion  about  the  Egyptian  armed 
forces  integrated  information  system,  we  can  conclude  that 
the-  first  step  should  be  the  design  of  the  organization 
structure  system.  All  of  the  systems  included  in  the 
integrated  information  system  need  informat io,  about  the 
organization  structure  of  the  units  and  formations  and/or 
information  related  to  the  organization  table  and/or 
->nt  table  for  units. 


arm  ■ 


The  organization  structure  system  may  be  designed  and 


implemented  by  itself  because  the  original  source  of  data  is 


the  Organization  Instruction  for  units.  The  percentage  of 


completeness,  location,  and  defense  plan  may  be  changed  by 


operational  instruction.  Later,  this  may  be  done  through 


the  interface  with  the  command  and  control  system.  For 


those  reasons,  the  scope  of  the  project  will  be  the  design 


of  the  organization  structure  information  system  using  a 


data  base  management  system.  The  implementation  will  be 


done  as  time  permits.  The  designed  model  should  define  and 


manipulate  the  following  data  which  is  described  earlier  in 


this  paper 


Organization  Instruction  Number 


2.  Unit  Name 


3.  Main  Branch 


4.  Sponsor  Department 


5.  Unit  Level 


6.  Unit  Type 


7.  Unit  Number 


8.  Percentage  of  Completeness 


9.  Balance  Type 


10.  Location 


1 1 .  Comment  Unit 


12.  Commanded  Sub-Unit(s) 


13.  Defense  P 1  a • 
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14.  Organization  Table 

15.  Armament  Table 

The  thesis  work  will  cover  the  following  areas: 
Definition  of  the  System  E-R  Model 
Definition  of  the  System  F-D  Model 
Choice  of  DBMS  Model 
Normalization  (if  necessary) 

Design  of  Conceptual  Data 
Implementation  (as  possible) 

System  Recovery  and  Concurrency 
System  Security  and  Integrity 
System  Interfaces 

This  thesis  work  will  cover  the  current  information 
about  the  organizational  structure  of  several  Egyptian 
r  . litary  organizations.  Ttv'  information  is  needed  fnv 
planning  and  management  of  t  h"  armed  forma.,  o :  j  •  .'•/.{*  ion 
structure.  The  implementation  of  this  project  keeps  the 
consistancy  and  correctness  of  data  over  all  of  the  armed 
forces  organization. 


The  E-R  model  is  one  of  the  most  useful  tools  to 


summarize  the  designed  data  base  information  that  may  be 
represented  as  three  different  types: 


Ent  it' 


The  term  "entity"  is  widely  used  in  data 
base  circles  to  mean  any  distinguishable 
object  that  is  to  be  represented  in  the  data 
base .  (2:10) 


A  group  of  similar  entities  may  form  an  entity  set.  The 
entity  will  be  represented  by  rectangles. 

At  t  r i DU  t  e 

Entities  have  properties  callei  attributes, 
which  associate  a  value  fro.;  a  domain  of 
values  for  that  attribuie  with  each  entity 
in  an  entity  set.  (8:6) 

The  attributes'  definition  for  each  entity  is  an  impor¬ 
tant  step  in  data  base  design.  If  an  attribute  or  a  set 
of  attri'  :!:es  whose  values  uniquely  identify  each  entity  in 
an  entity  set  is  called  a  key  attr ibute ( s ) ,  the  attributes 
will  be  represented  by  circles  (or  ovals)  and  the  key 
attribute  will  be  marked  by  an  asterisk. 


Re  lationshii 


A  relationship  among  entity  sets  is  simply  an 
ordered  list  of  entity  sets.  A  particular 
entity  set  may  appear  more  than  once  on  tt-  •  list. 
If  there  is  a  relation  i.p  REL  among  entity 
sets  Ej_f  ?,2 1  .  ..,  E^ ,  then  it  is  presumed 


that  a  set  of  k  tuples  named  REL  exists.  We  call 
such  a  set  a  relationship  set.  Each  k-tuple 
(el,  •••»  ek  i-n  set  REL  implies  that 

el*  e2>  •••»  ek»  where  e^  is  in  set  E]_, 
e2  is  in  set  E2/  and  so  on,  stand  in 
relationship  REL  to  each  other  as  a  group.  (8:7) 

The  relationship  will  be  represented  by  diamonds. 

Entity  Types 

Figure  5  illustrates  the  designed  E-R  model  for  the 
system.  The  newly  established  unit  may  follow  one  of  the 
existing  models  (as  described  in  the  last  section),  or  it 
may  be  established  by  a  new  unit  model.  For  example,  all 
M60-43  tank  battalions  have  the  same  structure  (i.e.,  they 
follow  the  same  unit  model).  Five  entity  types  are  defined; 
the  first  one  is  "Unit-Model"  which  represents  a  prescribed 
structure  of  units  that  may  be  followed  by  a  newly  estab¬ 
lished  unit;  the  second  one  is  "Unit"  which  represents  an 
existing  real  unit.  Two  entity  types  "Person"  and 
"Armament"  describe  both  personnel  and  armaments  assigned  to 
the  predefined  unit-model.  The  last  entity  type  is  "Plan" 
which  describes  assigned  plan  for  unit  (See  Figure  5). 


Attribute  Types 

Unit  Model  Attributes. 

There  are  th-t>e  attributes  (udep,  level,  type)  that 
uniquely  identify  the  unit-model  and  another  three 

a  '  •  ’  h'.i  t  e . 

'  •(>  -  u  r  :  *  sponsor  (!•  p  1  r  t  merit  number.  I  >  >  .  a 

2  -  d.  jit  into.:  •  number  rang:  n  ;  from 
1  to  99. 


*Level  -  Unit  level  (division,  brigade, 

battalion,  etc.).  It  is  a  2-digit 
integer  number  ranging  from  00  to 
99  (level  00  represents  MOD  only). 

*Type  -  Unit  type.  If  the  unit  is  infantry 

battalion,  this  attribute  describes  its 
type  (mechanized,  air  born,  amphibious, 
etc.).  It  is  a  2-digit  integer  number 
ranging  from  00  -  99.  (Type  00  means 
that  this  unit  has  only  one  type,  e.g. 
MOD,  Infantry  Department.) 

Uname  -  Unit  name  like  "mechanized  infantry 

brigade".  Unit  name  may  identify  the 
unit  model  and  it  is  regarded  as 
candidate  key  (a  relation’s  attribute 
that  uniquely  identifies  all  relation's 
attributes  is  called  a  candidate  key). 
We  must  add  unit  number  (the  key 
attribute  of  unit  entity)  to  Uname  to 
be  "Mechanized  Infantry  brigade 
Number  115".  It  is  represented  by  a 
string  of  30  characters. 

Balance  -  It  represents  the  unit  balance  type 
(command  &  control):  fighting, 
fighting  assistance,  logistic, 
technical,  and  training.  It  is 
represented  by  an  integer  number 
ranging  fro:"  1-6. 

Main  Branch  -  The  main  branch  which  the  unit 

model  belongs  to  (army,  navy,  air 
force,  air  defense,  border  guard) 
Its  domain  is  the  set  of  values 
(AR,  NA,  AF,  AD,  BG) . 

Person  Attributes. 

Person  entity  repr.  -its  the  organization  table  as 
described  in  Figure  2.  There  are  two  key  attributes  and 
another  attribute. 

*Pdep  -  Person  department  number.  It  is  the 

sp-  .  ialized  depart;.  •  u ‘  responsible  for 
supplying  the  unit  wiih  the  d-'fined 
type  of  personnel.  It  is  a  2-digit 
number  ranging  from  01  -  99.  1  no 

sai  ••  a*- tribute  value  as  U  !  ••  .  ’ 


♦Specialization  -  It  is  defined  as  the  person 
specialization  and  it  is  one  out  of  six 
specializations  (officer,  secretary, 
commission,  driver,  technician,  or 
craftee) .  Its  domain  value  is  the  set 
(off.  Sec,  Com,  Dri,  Tec,  Cra) . 

#P  -  It  is  the  attribute  of  the  relationship 
assigned  personnel  and  it  is  the  number 
of  personnel  from  the  predefined  Pdep 
and  specialization.  It  is  an  integer 
number  ranging  from 
0  -  999. 

Armament  Attributes. 

Armament  entity  represents  the  armament  table  as 
described  in  Figure  3.  There  are  two  key  attributes  and 
another  one. 

*Adep  -  Armament  department  number.  It  is  the 
specialized  department  responsible  for 
supplying  the  unit  with  the  defined 
type  of  arms  or  equipment.  It  is  a 
2-digit  number  ranging  from  01  -  99. 
(the  same  attribute  domain  as  Udep.) 

♦name  -  Arm  or  equipa.-:  t  name.  It  is 

represented  by  30  Character  String. 

# A  -  It  is  the  attribute  of  the  relationship 
assign  A  &  E  and  it  represents  the 
number  of  arms  or  equipments  predefined 
by  both  Ad op  and  name.  It  is  an  integer 
number  rangingfrom  0  -  999.  (The  same 
attribute  value  as  #P.) 

U  f  i  L  _  At  tributes . 

There  is  only  one  key  attribute  (U#).  This  attribute 
does  not  uniquely  identify  a  unit.  Unit  is  identified  by 
urnt-model  keys  (udep,  level,  type)  and  U#. 

♦U#  -  unit  number.  This  attribute  defines 

the  unit  number  for  an  existing  (or  new 
established)  unit  which  has  a  unit  model 
existing  in  the  enrit-v  set  Unit -Model. 


If  the  unit  model  can  represent  only  one 
unit  (e.g.)  unit  model  of  MOD  or  logistic 
authority,  the  unit  number  will  be  zero. 
Otherwise,  the  unit  number  will  be  greater 
than  zero.  Units  of  different  unit  model 
may  have  the  same  U#.  U#  is  represented  by 
an  integer  ranging  from  0  -  999. 

Percentage  -  percentage  of  completeness  of  the 
unit  from  personnel  (in  peace  time).  It  is 
an  integer  ranging  from  0  -  100.  (As  a 
matter  of  fact  there  is  no  zero  percentage  of 
completeness  as  it  means  no  personnel 
in  this  unit  but  it  may  be  considered  for 
special  cases  of  reserve  units  where  the 
whole  unit  is  stored.) 

Locat ion  -  The  geographical  location  of  the  unit. 

Egypt  is  divided  into  six  military 
locations  (A,  B,  C,  D,  E,  F).  Its 
domain  value  is  the  set  (A,  B,  C,  D, 

E,  F)  . 

I  [.at  ruction  #  -  The  organization  instru:t.  Lon 

number  that  establishes  the  unit.  It  is 
represented  by  an  integer  number  ranging 
from  1  to  99999. 

P 1  a : .  A ;  ■  r i bu t e . 

!’ mid  -  The  d  fenso  plan  (s)  w!  the  unit  has 
a  mission  with.  The  unit  may  be  assign 
to  more  than  one  defense  plan  and  more 
than  one  unit  may  have  the  same  plan 
(min).  Its  domain  value:  is  the  set  of 
Alphabet  (A,  B,  C,  ...,  Z). 


Reha  '  o n s h  i  p s 

Fir.  .  •  ,  relationship  "establish  ■  !"  1  ■ .  Un  i  t-M  •  .1  •  1  a: 

Unit  represents  that  each  unit  is  established  within  a  unit 
model.  As  m  my  units  may  have  the  same  model,  the 
relation-;;.::)  is  a  one  to  many  relat  ions!;  ip.  Second  and 
thirl  relationships  "assign  personnel"  and  "ass.  :  A  5.  E" 


represent  the  relationship  between  unit  model  and  personnel 
and  armaments  assigned  to  that  unit  model  consequently. 

Both  relationships  are  many  to  many  (more  than  one 
occurrence  of  the  first  entity  may  be  assigned  to  one 
occurrence  of  the  second  entity,  and  more  than  one 
occurrence  of  the  second  entity  may  be  assigned  to  one 
occurrence  of  the  first  entity).  Different  personnel  from 
different  departments  and  different  specializations  may  be 
assigned  to  the  same  unit-model,  and  personnel  from  the  same 
department  and  from  the  same  specialization  may  be  assigned 
to  different  unit  models. 

The  fourth  relationship  "command"  represents  the 
hierarchical  relationship  between  units.  The  command  unit 
(which  is  unit)  commands  a  set  of  units  and  each  unit 
(except  MTD  which  represent  the  rest  of  the  tree)  is 
commanded  oy  only  one  unit.  Therefore,  all  units  (except  the 
root)  are  involved  in  this  relationship.  The  other  option 
to  represent  the  "command"  relationship  is  to  consider  the 
command  1  units.  From  this  point  of  view  we  can  see  that 
all  unit.;  u  ive  commanded  units  except  "leaf-units".  The 
num:  of  units  involved  in  the  seco-  i  option  of  the 

re  la<-  ionship  is  much  fewer  than  first  option;  therefore,  wo 
..  ’  ’  choose  th-  .  •  ‘  —  w  i  id  option.  The  last  relationship  is 
as:;  iqn-Lo  describes  which  unit  is  assigned  to  which 
plan  (a).  This  relv  :  -  .hio  is  a  many  to  many  re  1  i‘  ionship. 
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Function  Dependency 

The  entity  Unit-Model  has  three  key  attributes  (udep, 
level,  and  type).  These  three  key  attributes  define  uname 
and  balance  as  described  in  Figure  6. a.  The  other  attribute 
"main  branch"  can  be  defined  by  udep  only. 

The  relationship  "assign  personnel"  is  a  many  to  many 
relationship  between  unit-model  and  personalities;  #P  can 
be  defined  by  means  of  the  key  attributes  of  both  entities 
(udep,  level,  type,  Pdep,  and  specialization)  as  described 
in  Figure  6.b. 

A  similar  functional  dependency  exists  between  Unit- 
Model  and  armament  entities;  #A  can  be  defined  by  means  of 
the  key  attributes  of  both  entities  (udep,  level,  type, 

A cup ,  and  name)  as  described  in  Figure  6.c.  The  unit 
attributes  percentage,  location,  and  instruction  #,  are 
def  in  :>y  Unit  Model's  key  attribu!  .  Ud--p,  level,  and  type 
and  Unit's  key  attribute  Uif  (see  F  i  jure  6.  a). 

The  last  relationship  "command"  describes  the  command 
unit  for  e  .  h  unit.  Therefore,  the  command  unit  key 
a^tribu"-  •  •  p,  clevel ,  ctyp  ■  nd  cu#  (c  s-  and-;  for 

co.::.  '-1  ur;i.t  just  to  eliminate  ambiguity)  are  defined  by 


t  at  tributes  udep,  level,  type,  and  U#  (see  Figure  6.^). 


6-c .  Function  Dependencies  for  Assign  A  & 


Figur--  6.  Function  Dependencies  Diagram 


E  Relationship 
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V .  Design  of  Data  Base 


Choice  o£  DBMS  Model 

The  process  of  choosing  a  DBMS  Model  for  implementation 
needs  to  compare  the  feature  of  the  three  main  DBMS  models; 
hierarchical,  network,  and  relational  models  which  will  be 
represented  by  DL/ 1 ,  IDMS,  and  SQL,  respectively.  This 
comparison  will  be  done  through  a  framework  for  the 
evaluation  of  data  model  which  is  described  by  Vasta 
(9:219-226).  Figure  7  summarizes  this  framework  of 
evaluation  (9:220). 

General  Considerations. 

Data  Building  Blocks. 

It  is  the  smallest  unit  of  data.  It  is  defined  as 
a  f  ield  in  D!  ,  data  item  in  IDMS,  and  attribute  in  SQL. 

The  data  t:  unit  is  a  segment  in  D L / 1 ,  and  a  Record  in 

IDMS.  The  relational  model  has  an  advantage  over  the  two 
other  models;  it  offers  two  units  of  data  transfer.  SQL 
permits  transfer  of  one  tuple  at  a  time,  and  when  data  is 
operated  upon  through  an  on-line  terminal  in  SQL,  th-  units 
cf  data  transfer  is  a  table  (8:221). 

Representation  of  L ogica 1  D a t a  Structure . 

The  logical  data  structure  of  the  design  model  as 
■.’.■•scribed  by  L-n  diagram  (Figure  5)  repr~  o  two  one  to 
many  re  la '  Lons'.:  i  p.;  and  three  ■  La  many  relationships. 


HERARCHICA! 


RELATIONAL 


Representative  system 

OL/I  (BV 

tOWS  (Cufen* 

SOL — the  OML  tor 

BMa  DATABASE  2 

Data  bufang  btxxs 

Field 

Data  item 

AttnOuta  (coAmn! 

Segment 

Peart 

Tuple  (row, 

Physical  data  dam 

Set 

Racaaor  (table; 

Representation  of  logic a 

data  SbUCtureS 
—  Tree i 

b'tctfy 

Decomposition  mo  sets 

Oaoomposmor  nto  tablet 

—Simp*  netwonc 5 

UnDnctioa!  bga 

Decomposition  me  secs 

Decomposition  mo  tablet 

ratabonship 

— Comp*  i  notwcrkj 

Bidirectional  logca  ' 

D*compo*it>or  mo  Mt] 

Decomposition  mo  tabtat 

relationship 

using  ntersection  data 

uarig  ntersection  data 

Data  rd*p*x)*ncf 

—Path 

NO 

No 

Yas 

— Sequence 

No 

No 

Yas 

DMl  aynmj/xfs 

— Retrieve: 

GU  GHU.  GN.  GHN 

GNP.  GHNP 

Ifind 

Jget 

|  SELECT 

— Data  alteration 

REPL 

MODIFY 

UPDATE 

— Qjfta  addition 

ISPT 

STORE 

INSERT 

—Data  datatKm 

Dirr 

ERASE 

DELETE 

—M  $ce"a-i&ous 

READY.  FINISH 

CONNECT.  DISCONNECT 

Means  o'  data  base 

Through  hierirchica.'  path 

Through  sets 

Through  Iha  value 

navigation 

Ot  Iha  aonoutrs 

Havigator 

Eipenencad  trained 

Expenenoed  treated 

End  uaar 

programmer 

programmer 

Performance 

High— with  wel; -defined 

High— with  w*i>  defined 

High — with  unstructured 

access  paths 

access  p*r< 

access  paths 

Low— with 

Low — with 

Low  (r  companeon  to 

urwthjctu'ed 

unstructured 

NararcNcaJ  and  network 

•ccesj  P<1  *  j 

access  paths 

data  models)— with  wef- 
deftned  access  paths 

Additional  pointers 

Ym — retrieve 

Yes— retrieval 

Yas — but  SQL  may 

available  to  mprove 
performance 

choosa  not  to  uaa  them 

Security 

Defined  r  eufcvhema 

Defined  n  aubschena 

Defined  in  subschema  — 

but  may  t*  modified  at 
any  Dme  including 
during  orvlna  execution 

Security  officer 

DBA  or  equivalent 

DBA  O'  equrvaient 

DBA  or  equivalent— 

may  ba  datagatad 

Responsibility  tor  adding 

Data  Dam  man«v»r--*ot 

Data  basa  management 

Data  basa  managamant 

data  to  the  da's  N* u* 

ayttem — governed  by 

system  or  apptcahor 

■yetem 

USERT,  REPLACE, 

prog'i"— governed  by 

DELETE  rvt*» 

Insertion  ju  i .« 

Uodihcaoon  of  the 

Redefine  atructura,  ra'-c.-L 

RedeNie  strjcJiri  reload 

Restructure  at  any  lima. 

data  structure 

nee  structure 

naw  structure 

Inducing  operation  In  an 
orvlna  environment 

The  logical  data  structure  may  be  represented  as  a  network. 
The  network  structure  cannot  be  represented  directly  by 
DL/ I .  Data  is  represented  as  if  it  were  duplicated.  Data 
are  reproduced  in  two  different  segments  in  a  tree  structure 
then  logical  pointers  are  used  to  eliminate  redundancy. 
Network  model  represents  many  to  many  relationships  by 
creating  a  record  type  which  contain  intersection  data  for 
records  involved  in  the  many  to  many  relationship.  The 
intersection  record  is  a  member  in  each  of  two  sets  in  which 
the  related  records  are  owners  (8:221).  Relational  model 
also  creates  an  intersection  relation  including  primary  keys 
of  the  relations  involved  in  the  many-to-many  relationship. 

Data  Independence. 

DU  l  allows  logical  sequencing  of  segments  and 
permits  so  .-ondary  indices.  While  this  provides  great 
flexibility  to  the  application  program,  it  causes  secs-  ,.:e 
dependency  and  also  path  dependency  since  the  desired 
segments  is  obtained  through  a  specific  path.  IDMS  is  also 
subject  to  the  same  sequence  and  path  dependency. 

In  relational  model,  pointers  are  not  used  and  the 
relationship  i kept  through  the  tables'  attributes.  In  a 
r- 1  at iona 1  model,  columns  and  rows  may  be  presented  in  any 
order  (i.e.,  there  is  no  ific  sequence  that  must  be 

followed*).  Therefore,  the  relational  mod  -1  is  free  from 
^eth  sequence  and  path  dependency. 
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Navigator . 

Navigation  is  done  in  both  hierarchical  and  network 
models  through  specific  paths.  In  a  hierarchial  model,  it 
is  done  through  the  traversal  of  the  tree  structure  and  in  a 
network  model,  through  the  traversal  of  owner  and  member 
sets.  In  both  models,  the  navigator  must  know  the  current 
location  in  the  data  base  and  the  direction  of  the  desired 
data  item.  Therefore,  a  highly  trained  programmer  is 
needed . 

Because  of  the  data  independence  in  the  relational 
model,  there  is  no  specific  path  to  follow,  and  the  data  is 
obtained  by  defining  the  value  of  the  attributes  within 
relations.  It  is  not  necessary  to  keep  track  of  the  current 
data  base  position,  or  to  describe  how  to  find  the  data. 
Therefw:_,  there  is  no  need  for  a  highly  trained 
programmer.  The  end  user  with  little  training  can 
manipulate  data. 

Performance . 

In  a  hierarchical  model,  the  specific  paths  which 
are  defined  by  pointers  permit  rapid  retrieval  of  desired 
data.  The  same  situation  is  also  in  a  network  model.  On  the 
other  hand,  "neither  IDMS  nor  DL/ I  is  well  suited  to  an 
unstructured  environment  where  data  relationships  can  be 
changed  while  the  user  is  accessing  the  data  base" 
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The  relational  model  needs  greater  space  than  both 
the  hierarchical  and  network  models.  SQL  is  more  powerful 
as  it  performs  operations  on  many  tuples  within  a  single 
query.  Where  DL/ I  and  IDMS  operate  on  one  record  or  segment 
at  a  time  and  may  require  many  commands  to  accomplish  one 
SQL  command. 

Security. 

In  a  DBMS,  security  is  defined  on  the  level  of  the 
subschema.  In  both  DL/ I  and  IDMS,  the  subschema  definition 
is  translated  before  execution.  In  SQL,  the  definition  of 
the  subschema  may  be  modified  at  any  time.  (8:224) 

SQL  has  additional  security  tools;  that  is  "Grant 
and  Revoke"  mechanism  and  "view"  mechanism.  The  view 
mechanism  allows  the  data  to  be  conceptually  divided  up  in 
such  a  way  to  that  some  data  may  be  hidden  from  unauthorized 
users.  The  Grant  and  Revoke  mechanism  or  the  authorization 
subsystem  lets  the  authorized  user  grant  rights  to  any  other 
user(s)  but  not  exceeding  his  own  rights,  and  also  Revoke 
granting  rights  to  the  user  he  granted  and  any  other  user 
that  granted  user  rights  (z:441-443). 

Modification  of  the  Data  Structure. 

Since  both  hierarchical  and  network  models  are  data 
dependent  a-H  the  data  are  linked  together  in  such  a  way 
that  it  is  needed  to  follow  a  certain  path  to  retrieve  a 
specific  segment,  modification  of  data  structure  needs  a 
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working  copy  of  the  data  base(s)  to  be  made,  a  new 
definition  of  the  data  structure,  and  then  recreate  the  data 
base  in  the  new  structure  from  the  working  copy.  While  the 
restructuring  is  occurring,  programs  may  not  access  or 
modify  the  existing  data  (9:224).  In  case  of  relational 
model,  the  DBMS  is  data  independent,  so  the  data  structure 
may  be  modified  at  any  time  while  the  system  is  running  and 
without  recreation  of  the  data  base. 

Comparison  of  Mode  1 s . 

From  the  above  discussion  and  considering  the  shape  of 
the  data  base  that  is  defined  by  the  E-R  model  described  in 
Figi  re  5,  we  can  summarize  our  data  base  features  as: 

1.  Th'*re  are  two  one-to-many  re lat ionships  and 
t  n  r  •.  •  many  to  many  relationships. 

2.  inuro  must  be  an  algorithm  to  create  the 
formation  hierarchical  relation  (the  relation 
that  contains  the  set  of  units  which  are  commanded 
by  a  particular  unit)  from  the  command  relation 
(the  relation  that  defined  the  subunits  (if  exist) 
for  each  unit )  . 

3.  We  should  consider  that  the  data  base 
will  have  many  interfaces  to  other  systems 

(s  F  i  ure  1)  and  the  homogenious  aspects  of 
DBMd  tor  the  armed  force  integrated  system. 

Fr.  o.i  the  above  features  of  the  data  base  we  will  exclude 
th°  hierarchical  model  from  our  consideration  for  the 
following  main  reasons: 

1.  There  a1'  !  many  to  many  relationships. 


2.  Hierarchical  model  cannot  represent  a  network 
directly;  instead,  it's  decomposed  into  many 
tree  structures  that  may  cause  data  redundancy. 

Now  the  comparison  will  be  done  between  the  network 

model  and  the  relational  model. 

Network  Model. 

Advantages ; 

1.  Simple  representation  of  network 

2.  Rapid  Response 
Disadvantages : 

1.  Data  dependent 

2.  Needs  experienced  programmer 

3.  Modification  of  data  structure  needs  to 

redefine  structure  and  related  new 
structure . 

Relational  Model. 

Advantages ; 

1.  The  data  transfer  unit  may  be  a  tuple  or  a 
whole  table. 

2.  Data  independent. 

3.  Simple  data  manipulation,  that  end  user  with 
little  training  can  manipulate  the  data. 

4.  Additional  security  tools  (view, 
Grant-Revoke)  . 

5.  Easy  modification  of  data  structure. 


Disadvantages : 


1.  Needs  greater  space. 

2.  Slower  response. 

Choice  Considerations. 

From  the  above  discussion  and  from  the  advantages  and 
disadvantages  of  network  and  relational  model,  consider  the 
f o 1  lowing : 


1.  The  designed  data  base  will  have  interfaces 
to  other  systems  that  most  likely  to  use 
rational  models. 

2.  "Networks  are  complex  and  the  structure  is 
complex.  This  increase  in  complexity 
compared  with  relational  system  does  not 
lead  to  any  corresponding  increase  in 
functionality"  (2:574). 

i.  To  keep  the  integrated  system  as  a  homogenous 
system,  we  should  use  the  same  DBMS  model. 

4.  Ability  to  have  relational  model  for  the 
Egyptian  VAX  systems. 

From  the  above,  the  chosen  data  base  model  is  the 
relational  model  and  the  implementation  will  be  done  within 
DBMS  on  a  VAX  780  (SSC  system). 


D-'.-;  Lgn  of  Logical  Data 


In  a  relational  data  bn".,  model,  the  data  base  is 
arranged  into  two  dimension  tables  (relations).  Each 
oceur  tance  of  data  (row)  is  called  a  tuple.  A  tuple 
consists  of  one  or  more  properties  called  attributes.  Each 
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attribute  can  take  on  a  specific  set  of  values  over  a  period 
of  time.  All  the  values  that  an  attribute  can  take  on  are 
called  the  domain  of  the  attribute.  (9:198-199). 

Retrieving  the  E-R  model  described  in  Figure  5,  we  will 
start  defining  the  data  base  relations  as  a  relation  for 
each  entity  and  for  each  attribute.  The  second  step  is  to 
use  a  computer  normalization  tool  to  normalize  any 
non-normal ized  relation  to  third  normal  form  (if  any). 

Direct  Relations  Definition. 

The  direct  relations  definition  for  the  data  base 
described  by  the  E-R  diagram  (Figure  5)  will  be  described 
below.  The  relation  name  will  precede  the  relation.  The 

preceding  an  attribute  represents  it  as  a  key  attribute: 

1.  Unit  Model 

*  dep 

*  level 

*  type 
name 
balance 
main  branch 

2.  Person 

*  p  ’ 


..pec  ial  izat  ion 


Armament 


*  Adep 

*  name 

Assign  Personnel 

*  dep 

*  level 

*  type 

*  Pdep 

*  special ization 

#  P 

Assign  -  A  &  E 

*  dep 

*  level 

*  type 

*  Adep 

*  name 

#  A 
Unit 

*  dep 

*  1  e  v  e  1 

*  type 
U# 

Percentage 

Location 


Instruction  # 


7. 


Plan 


*  dep 

*  level 

*  type 

*  u# 

*  Plan 
8.  Command 

*  c  dep 

*  c  level 

*  c  type 

*  c  U# 

*  dep 

*  level 

*  type 

*  U# 

Norma  1 i za  t ion . 

The  purpose  of  normalization  is  to  design  data 
structures  in  such  a  manner  as  to  eliminate  the  need  to 
redesign  them  when  new  applications  are  added.  By 
sto.  ng  data  in  the  third  normal  form,  structures 
designed  today  can  be  integrated  with  new  application  in 
the  fuMire  with  little,  if  any,  redesign  effort 
(  y  :  2  j  4  -•  <:  _■ .) )  . 

Using  a  CAN  normalization  tool  which  i  ..  unning  on 
Lh !  - 1  1  System  "A"  by  Mallory  (■’.),  w°  found  tnat  the  two 
i  Td  t  ions  th  d  n  .■  ■  i  further  norma  1  i  za  t  ion .  The  first 
relation  Unit-Model  is  normalized  as  the  foil  ..  ,  ng  two 
1  a t  ions : 


5r. 


1.  Unit-Model. 


*  dep 

*  level 

*  type 
name 
balance 

2  .  Department . 

*  den 

main  branch 

The  plan  relation  is  normalized  to  the  following 
two  relations: 

1 •  PLAN. 

*  dep 

*  level 

*  type 

*  U? 

*  plan 
2 .  PLANID. 

*  id 

Data  Definition 

The  data  base  of  the  organization  structure  of  the 
Egyptian  armed  forces  after  the  normalization  step  will  be 
presented  in  ten  relations.  Referring  to  the  attributes 
'.scription  presented  previously  and  using  ingres 
notations,  the  data  base  will  be  defined  as  the  following 
set  or  relations: 
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Unit  Model 


Attribute  Name 

Type 

Domain 

*  dep 

C  2 

digits  01:99 

*  level 

C  2 

digits  00:99 

*  type 

C  2 

digits  00:99 

name 

C  30 

Alpha  numeric 

balance 

C  1 

digits  1:6 

Department 


Attnoute  Name 


branch 


Type 

Domain 

C  2 

C  2 

digits  01:99 

(AR,  NA,  AF, 

AD,  BG) 

Pe  c  ;ion 


Attribute  Nam 


Domain 


P  dep 
*  Spec 


digits  01:99 
(Off,  Sec,  Co 


Armament 


Attribute  Name 

Type 

Domain 

A  dep 

Name 

C  2 

C  30 

Digits  01:99 

Alpha  Numeric 

AssignP 


Attribute  Name 

Type 

Domain 

* 

,,  : ) 
i. 

C  2 

Digits  01:99 

* 

1  *£?  V  i. 

C  2 

Digit.''  0  3:99 

★ 

type 

C  2 

Digits  0u:99 

★ 

Pdop 

C  2 

Digits  01:99 

★ 

Spec 

C  3 

(Off,  Sec,  Com, 

Dri,  Tec,  Cra) 

N 

iUMP 

i  9 

1 nteger  1:9999 

Attribute  Name 


Type 


Domain 


*  dep 

C  2 

Digits  01:99 

*  level 

C  2 

Digits  00:99 

*  type 

C  2 

Digits  00:99 

*  Adep 

C  2 

Digits  01:99 

*  Name 

C  30 

Alpha  Numeric 

num 

i  3 

Integer  1:999 

7.  Unit 


: T  c  ibute  N  ! 

Type 

Domain 

*  dep 

C  2 

Digits  01:99 

*  level 

C  2 

Digits  00:99 

*  type 

C  2 

Digits  00:99 

*  Num 

C  3 

Digits  0  u 0  :  9  9  9 

Percentage 

i  4 

Digits  0:100 

Loca  t i on 

C  1 

(AfB,C,D,E,F) 

Instruction 

C  5 

Digits  00001:99999 

Attribute  Name 

I  Type 

Domain 

*  dep 

C  2 

Digits  01:99 

*  level 

C  2 

Digits  00:99 

*  type 

C  2 

Digits  00:99 

*  Num 

: 

C  3 

Digits  000:999 

*Plan 

C  1 

( A ,  B i  •  •  •  §  Z) 

Planid 


Attribute  Name 


Command 


Attribute  Name 


*  C  dep 

*  C  level 

*  C  type 

*  C  Num 


Type 

Domain 

C  1 

(A,  B ,  • • • §  Z) 

Type 


Domain 

Digits 

01: 

99 

Digits 

00: 

99 

Digits 

00: 

99 

Digits 

000 

:  999 

Digits 

01: 

99 

Digits 

00: 

99 

Digits 

00: 

99 

Digits 

000 

:  999 

C  2 


The  new  data  base  "OMADB"  ( OMADB  stands  for 
Organization  and  Management  Authority  Data  Base)  is  created 
under  UNIX  operating  system  using  ingress.  OMADB  consists 
of  the  ten  relations  UNITMODEL,  DEPARTMENT,  PERSON, 
ARMAMENT,  ASSIGNP,  ASSIGNA,  UNIT,  PLAN,  PLANID,  and 
COMMAND.  Ingres  data  definition  of  the  relations  is 
presented  in  Appendix  A. 


V I .  Data  Manipulation 


The  data  manipulation  will  be  done  through  Ingres  Data 
Manipulation  Language  (DML).  Ingres  uses  English-like 
commands  to  manipulate  data  within  relations.  Each  relation 
represents  a  table  which  is  identified  by  name.  Each  row 
represents  a  tuple,  each  column  represents  an  attribute  of 
the  relation  which  is  identified  by  name.  Ingres  provides 
two  sets  of  commands;  the  data  definition  commands  that  let 
the  user  define  the  needed  information  (ask  questions),  and 
data  manipulation  commands  for  insertion,  updating,  and 
deleting  data.  The  user  need  not  be  awar°  of  whether  he 
uses  base  table  or  view  to  retrieve  the  required  information 
(vi-.-ws  represents  the  visible  data  for  the  us*jr  and  it  will 
be  discussed  later  in  Chapter  VII).  To  repr- »ent  data 
manipulation,  let  us  start  building  the  physical  data  base 
for  the  hypothetical  formation  presented  in  Figure  8. 

Pnysical  Data  Base  Represendrat  ion 

Figure  8  presents  a  hypothetical  formation  of  units 
which  consists  of: 

1.  MOD  which  presents  the  root  of  the  tree. 

2.  Tre  oo  specialized  departments;  infantry, 
armor,  and  signal  corn  departments. 


Figure  8.  Unit  Formation  of  OMADB  Data  Base 


3.  Two  infantry  brigades  number  100  and  200 
(both  brigades  have  the  same  unit  model). 

4.  Four  infantry  battalions  number  10,  11,  20, 
and  21  (the  four  battalions  have  the  same 
unit  mode  1 ) . 

5.  Two  tank  battalions  number  100  and  200 
(both  battalions  have  the  same  unit  model). 

Description  of  Physical  Data  Base . 

All  departments  and  MOD  are  located  in  Location  A. 
Infantry  brigade  100  and  its  subunits  are  located  in 
Location  B.  Infantry  Brigade  200  and  its  subunits  are 
located  in  Location  C. 

All  departments  and  MOD  have  balance  Code  1.  All  other 
units  (in  the  sample  data)  have  balance  Code  2.  All  units 
have  main  branch  "AR"  (army).  Percentage  of  completeness 


for 

MOD  is  100%,  for 

departments  is 

70%, 

for 

brigade  100  an 

its 

subunits  is  90%, 

and  for  brigade 

200 

and 

its  subunits  l 

85%. 

MOD  is  in  plans  A,  B,  and  C.  All  departments  are  in 
plan  A.  Infantry  brigade  100  in  plans  B,  C.  Ir. r  intry 
brigade  200  in  Plan  B  except  tank  battalion  200  which  is  in 
pics  B  and  C.  Appendix  I  represents  the  personnel  and 
dLinament  tables  for  the  sample  units  as  described  in  the 
organization  instructions.  Representation  of  physical  data 
n  the  ten  relations  is  presented  in  Appendix  B. 


6  4 


of  OM 


Retrieval  of  Data 


-  I 

Retrieval  of  data  in  our  model  is  do-e  through  the 
ingress  data  manipulation  language  that  has  the  advantages 
of  relational  algebra  in  dealing  with  relations.  Ingres 
deals  with  data  as  a  set  of  data  items  (tuples)  compared 
with  the  traditional  methods  of  data  manipulation  that  deal 
with  each  data  item  separately  (record  by  record  or  segment 
by  segment).  In  the  particular  case  when  ingress  is  looking 
for  a  particular  tuple,  it  deals  with  it  as  if  it's  a  set  of 
data  items  consisting  of  one  tuple.  This  new  dimension  in 
data  manipulation  which  was  introduced  by  relational  algebra 
let  the  user  write  his  query  in  more  abstract  form  and  make 
it  easier  for  the  inexperienced  user  to  deal  with  the 
relational  data  case  management  system.  This  concept 
implies  that  dealing  with  data  in  sequential  order  (or  in 
any  other  order)  has  no  meaning.  The  reason  for  arranging 
the  tuples  in  a  particular  relation  is  either  to  reduce  the 
a-cess  time  or  a  required  output  format.  In  the  next 
section  we  will  introduce  some  examples  o:  questions  that 
our  system  can  support. 

Examples  of  System  Queries. 

Ingres  data  manipulation  language  ( DML )  may  be  done 
interactively  or  imbedded  in  other  languages  like  C. 

The  following  are  some  examples  of  queries  that  are 
r.-cessary  for  trie  management  of  the  organization  structure 


of  the  Egyptian  armed  forces.  These  queries  may  be  im¬ 
bedded  in  other  languages  or  simply  as  interactive  queries. 
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How  many  infantry  battalions  exist  in  location 


Ingres  DML : 

♦range  of  u  is  unit 
♦retrieve  into  temp  (u.num) 

♦where  u.dep  =  "10"  and  u  .  level  =  "06" 
♦and  u.type  =  "03"  and  u. location  =  "b" 


♦range  of  t  is  temp 

♦retrieve  (number  =  count  (tnum) 


Result 


How  many  officers  exist  in  a  tank  battalion? 
Ingres  DML: 

♦range  of  p  is  assignp 
♦retrieve  temp  (p.num) 

♦where  p.dep  =  "11"  and  p. level  =  "06" 

♦and  p.type  =  "07"  and  p.spec  =  "off" 


'range  of  t  is  temp 


v.ViivN-''  *N'V 


\  v.  •*«  •*  ** .  *./»**.  ^ «* .  ^  v.  «■*„  / 1 *> 


•  *V\,V 


*retrieve  (nump  =  sum  (t.num) ) 

*\g 

Result 

numP 
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Write  the  unit  name  and  unit  number  of  units 
located  in  location  C? 

Ingres  DML: 

♦range  of  m  is  unit model 
♦range  of  u  is  unit 
♦retrieve  (in.  name,  u.nuin) 

♦v.’here  u.bep  =  m.dep  and  u.  level  =  m.  level 
♦and  u.typ-  =  in.  type  and  u.  locat  ior  -  "c" 

*  Vi 

Resu  Its 


Name 

Nurn 

Infantry  Br  Lq  id” 

200 

Infantry  Battalion 

j 

020 

Infantry  Battalion 

021 

Tank  Ball  d  i  on 

200 

How  many  technicians  does  the  signal  corp 
department  supply  to  th**  arm'll  forces? 


Ingres  DML : 

♦range  of  a  is  assignp 
♦range  of  u  is  unit 

♦retrieve  into  temp  (a.dep,  a. level,  a. type, 
u.num,  nump  =  a.num) 

♦where  a.dep  =  u.dep  and  a. level  =  u. level 
♦and  a. type  =  u.type,  and  a. spec  =  "tec" 

♦and  a.pdep  =  "16" 

*\g 

♦range  of  t  is  temp 
♦retrieve  (tech  =  sum  (t.nump)) 

*\g 

Result  : 

tech  | 
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Write  the  unit's  nor  •  and  number  f  >r  the  units 
which  are  located  in  locaf.~.  C  and  in  plan  C? 
Ingres  DML: 

♦range  of  u  is  unit 

♦range  of  r,  is  unitmodel 

♦range  of  p  is  plan 

♦retrieve  into  Leap  (u.dep,  u. level,  u.type, 

u.num,  m.namo) 

♦where  u.dep  =  m.d>*p  and  u.  level  =  m.  level 


■-*  -  *-*  ■-*  »-»  »-■>■■ 


*and  u.cype  =  m.type  and  u. location  =  "c" 


*range  of  t  is  temp 
♦retrieve  (t.name,  t.num) 

♦where  t.dep  =  p.dep  and  t. level  =  P. level 
♦and  t.type  =  P.type  and  t.num  =  P.num 
♦and  P . plan  =  "c" 


Result 


Name 


Tank  battalion 


The  above  queries  are  examples  of  useful  output  that  may 
be  done  by  the  end  user  with  little  training.  Let  us  try  to 
answer  other  types  of  questions.  For  example,  how  many 
drivers  exist  in  the  formation  commanded  by  the  infantry 
brigade  100? 

To  answer  this  query,  we  first  must  know  what  units  are 
existing  in  this  formation.  The  command  relation  can  give 
us  the  set  of  units  that  is  .'Commanded  directly  by  the 
infantry  brigade  10.,  (i.e.)  one  level  of  the  formation 
hiermchy.  Unfortunately ,  we  do  not  know  how  many  levels  we 
should  travel.  For  that  reason  the  query  should  have  a 
recursive  feature.  Unfortunately,  neither  ingre  -,s  DML  nor 
equal  ( ''■mbuddod  ingress  in  c  language)  allows  recursive 


construe. 


From  the  above  information  and  to  let  our 
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system  answer  any  type  of  query  (about  the  data  in  the  ten 
relations),  we  need  an  algorithm  to  collect  the  units  that 
belong  to  a  particular  formation  or,  in  other  words,  get  the 
nodes  of  the  subtree  that  belong  to  a  specified  node  in  the 
armed  force  tree.  This  algorithm  will  be  introduced  in  the 
next  section. 

Collect  Formation  Unit  Algorithm. 

For  the  reason  of  keeping  the  set  of  units  that  is  under 
the  command  of  a  particular  unit,  we  create  a  new  relation 
in  the  system,  the  relation  formation  (dep,  level,  type, 
nun) .  This  relation  is  a  working  relation  to  keep  the  unit 
collection  of  the  required  formation  (the  output  of  the 
algorithm) .  Then  we  can  do  our  queries  about  that 
format  ion . 

The  algorithm  of  collecting  the  units  under  the  command 
of  goc  i  f  led  unit  is: 

1.  Get  the  command  unit  code  -  unit  node  is 
(dep/ leve 1 / type/ number ) . 

2.  Create  the  temporary  relation  parent  (dep,  level, 
typ-m  n.urn)  . 

3.  Create  the  temporary  relation  sons  (dep,  level, 
type ,  num) . 

4.  Delete  the  controls  of  the  relation  formation 
(if  any ) . 

5.  Append  to  parent  the  com  ■. r:  !  unit  -  unit  here 
means  unit  C'  ~ 
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6. 


Append  to  sons  the  units  that  are  commanded 
directly  by  any  unit(s)  which  exist  in  parent 
(using  command  relation). 

7.  Append  to  formation  all  units  in  parent. 

8.  Delete  the  contents  of  parent. 

9.  If  the  number  of  units  in  sons  <  1,  go  to 
Step  13  or  else  continue. 

10.  Append  to  parent  all  units  in  sons. 

11.  Delete  the  contents  of  sons. 

1 2 .  Go  to  Step  6. 

13.  Destroy  sons,  destroy  parent. 

14.  Exit. 

(See  Figure  9) 

This  i lgorithm  is  established  as  the  computer  program 
"tree"  (.•  Appendix  C). 

To  gev  the  set  of  units  th'd  is  commanded  by  a  specified 
unit,  f r.  j;r.  UNIX,  type  "tree".  The  program  tree  will  start 
running  and  it  will  let  you  enter  the  command  unit  data 
(dep,  lei  •!,  type,  num)  as  the  program  requests.  The 
program  will  ch  ’k  the  existence  of  the  command  unit.  If  the 
unit  does  not  exist,  or  if  the  input  format  is  not  correct, 
the  program  will  ask  you  to  reo.V  *r  the  command  unit  data 
again  or  to  cju  1 (by  typing  ’  Q  ’  )  •  If  the  entered  data  are 
cor  •  •  ,  the  program  will  start  execution  nr  :  the  output 
will  be  stored  in  the  relati  ■  formation.  If  the  entered 
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command  unit  is  a  leaf  unit  (command  no  unit),  the  relation 
formation  will  contain  this  unit  only  and  the  program  will 
let  you  know  by  an  appropriate  message. 

The  program  (TREE)  is  done  in  C  language  with  embedded 
ingres.  It  consists  of  a  main  body  (main)  and  3  functions 
(get-unit-model,  check  unit,  and  Ctree)  as  shown  in  the 
structure  chart  described  in  Figure  10.  TREE  program  is 
presented  in  Appendix  C,  and  a  copy  of  the  output  results  is 
presented  in  Appendix  D. 

The  answer  to  the  query  described  in  the  previous 
section  (how  many  drivers  exist  in  the  infantry  brigade  100) 
will  be  presented  in  Appendix  E  using  tree  program. 


relations  and  an  update  in  assigned  relation  may  violate  the 
integrity  of  the  data  base.  For  example,  if  we  are  trying 
to  delete  a  unit,  deleting  the  unit  from  unit  relation  is 
not  enough.  It  should  also  be  deleted  from  any  occurrence 
in  plan  relation  tuples  and  also  from  the  occurrence  in  the 
command  relation  as  a  commanded  unit.  Another  violation  of 
the  consistency  of  data  will  happen  if  we  delete  a  unit 
which  exists  in  the  command  relation  or  a  command  unit.  If 
we  only  do  this,  we  will  leave  its  subunit  be  commanded  by  a 
non-existing  unit.  In  this  case,  we  should  either  delete 
all  the  units  commanded  by  this  unit  or  quit  according  to 
the  user  request. 

The  updating  of  the  program  "OMAED"  which  is  presented 
in  Appendix  G  is  designed  to  perform  the  three  main  updating 
functions  (insertion,  deletion,  and  modification)  in  a 
certain  algorithm  so  that  it  keeps  the  data  integrity  over 
the  whole  system.  The  ability  of  retrieving  unit  data  is 
added  to  the  program  to  let  the  user  retrieve  unit  data 
according  to  his  request.  The  program  is  designed  in  menu 
driven  fashion  to  make  it  easy  to  use.  The  program  is 
’•  signed  in  main  body  and  2.2  functions  that  count  23 
modules.  The  structure  chart  of  OMAED  program  is  shown  in 
Figure  11. 

Insertion. 

To  ins  -  '*-  a  new  unit  into  the  data  base,  the  program 
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Main 


will  check,  the  format  of  the  unit  code  first  before  calling 
ingress,  then  it  checks  if  the  unit  exists.  The  system  does 
not  allow  the  existence  of  the  same  unit  twice.  If  these 
checks  are  passed,  the  program  will  check  if  the  new  unit 
has  an  existing  unit  model.  If  not,  it  will  ask  the  user  to 
enter  the  new  unit  model  data  and  it  gives  the  user  the 
chance  to  quit.  After  insuring  that  the  unit  model  exists 
(or  correctly  entered  by  the  user),  the  program  will  ask  the 
user  to  enter  the  unit  data  (unit  number,  percentage, 
location,  plan(s),  instruction  number,  and  command  unit). 

The  system  will  make  an  appropriate  check  for  each  entered 
piece  of  data.  For  example,  the  command  unit  should  be  an 
existing  unit,  plan  should  exist  in  pi an id  relation. 

After  insertion  of  the  data,  the  program  returns  to  the 
menu,  and  the  user  can  retrieve  the  entered  data  using  "r" 
option. 

Modi f ica t ion . 

To  modify  existing  unit  data,  the  program  will  check 
first  the  existence  of  the  unit  in  the  data  base,  then  it 
will  show  another  menu  to  select  one  of  the  following 
mod:.ication  options: 

modify  unit  percentage 
modify  unit  location 
modify  unit  plan 
modify  command  unit 


exit  (return  to  main  menu) 

For  every  selection,  the  program  will  ask  the  user  to  enter 
the  new  data,  then  it  makes  an  appropriate  check  on  it.  For 
example,  modification  of  plan  will  be  done  through  two  oper¬ 
ations,  either  to  assign  the  unit  to  a  new  plan  or  to  delete 
a  previous  assignment  for  plan.  To  do  that,  there  should  be 
two  types  of  checks,  one  to  insure  that  the  new  plan  exists, 
the  other  check  is  to  insure  that  we  will  not  try  to  delete 
a  plan  which  the  unit  is  not  assigned  to.  Modification  of 
command  unit  will  insure  that  the  new  command  unit  exists. 

De let  ion . 

To  delete  an  existing  unit,  the  program  will  start  a 
check  to  see  if  the  unit  exists.  If  so,  the  program  will 
give  the  user  a  chance  to  quit  by  asking  "Are  you  sure?"  At 
this  ste; ,  the  program  cannot  delete  the  unit  before  doing 
another  operation .  The  program  will  be  called  "Ctree" 
module  to  collect  the  unit(s)  which  are  comma  nd-H  by  the 
unit  in  question  into  the  relation  "formation".  If  there  is 
any  other  unit  in  the  relation  formation  rather  than  the 
unit  in  question,  the  program  -will  ask  the  user  again  if  he 
wants  'o  delete  all  subunits.  At  this  step,  the  us. :  has 
anof  chance  to  quit.  If  not,  the  pro  i  a  will  delete  the 
unit  and  all  its  subuni  t  (r;)  ,  if  any.  Deletion  is  done  in 
such  a  way  as  to  ku^p  the  integrity  of  data  base.  That  will 
i  ■  discuss'd  in  Chapter  VIII. 


VII.  Recovery,  Concurrency  and  Securit 


Recovery 

In  our  system,  the  problem  of  recovery  may  arise  due  to 
the  transaction  processinq.  The  transaction  is  a  logical 
unit  of  work.  When  executing  the  data  base  editing  program 
EDOMADB,  one  transaction  that  seems  to  the  user  as  one 
operation  may  be  a  sequence  of  several  operations.  For 
example,  deleting  a  unit  looks  like  a  single  transaction, 
but  actually  it  affects  three  relations.  One  tuple  must  be 
deleted  from  unit  relation,  another  tuple  must  be  deleted 
from  command  relation,  and  all  the  occurrences  of  this  unit 
in  plan  relation  must  be  deleted.  A  similar  situation  is 
done  when  insert i n  ;  a  new  unit.  A  system  crash  might  occur 
between  two  operations,  or  the  program  i ‘ self  might,  for  any 
reason,  terminate  between  the  two.  In  this  case,  the 
program  has  no  means  to  detect  in  which  stage  the  failure  is 
done.  The  recovery  should  be  done  on  the  system  level. 

A  system  that  support.",  transaction  processing  should 
provide  a  guar ant  e e  that  if  the  transaction  extern  -s  some 
u;d  y-o  and  then  a  failure  occurs  (for  whatever  reason) 
before  the  transaction  rea  u.js  its  normal  termination,  then 
those  updates  will  be  undone.  Thus  the  transaction  either 


executes  in  its  entirety  or  is  totally  canceled  (2:414). 


The  COMMIT  and  ROLLBACK  operations  are  the  key  to 

providing  the  system  recovery.  The  COMMIT  operation 

indicates  to  the  system  that  a  successful  logical  unit  of 

work  is  completed  and  the  data  base  is  in  a  consistent 

state.  The  ROLLBACK  operation  tells  the  system  that 

something  has  gone  wrong  and  a  transaction  is  unsuccessfully 

terminated.  In  this  case,  the  data  base  might  be  in  an 

inconsistent  state,  so  this  logical  unit  of  work  should  be 

undone  or  rolled  back.  COMMIT  and  ROLLBACK  (and  program 

initiation)  represent  a  synchronization  point  for  the  system 

and  at  this  synchronization  point  all  updates  made  by  the 

program  sin--'  the  previous  synchronization  point  are 

committed  (COMMIT)  or  undone  (ROLLBACK). 

Note  carefully  that  COMMIT  or  ROLLBACK 
terminate  the  transaction  not  the  program. 

In  general,  a  single  program  execution  will 
consist  of  a  sequence  of  several  transactions, 
running  one  after  the  other,  with  each  COMMIT 
or  ROLLBACK  operation  terminating  one 
transaction  and  starting  the  next.  (2:416) 

Another  type  of  failure  is  possible.  It  is  the  media 
failure  (such  as  a  disk  head  crash) .  In  this  case,  the  disk 
nas  beer:  •  ysically  destroyed.  Recovery  from  such  failure 
needs  to  reload  the  back-up  co;  v  of  the  data  Vise  and  uses 
the  log  (  ■.  ther  manual  or  in  the  computer)  to  redo  all 

transact  ion  .  that  have  been  done  since  the  previous  archive 
operation  for  *■  o e  back-up  copy. 

Back-up  copies  should  be  dor^  frequently  a..d  dno 
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data  base  state  reached  logged.  For  example,  use  the 
organi-  zation  instruction  number  reached  or  date  of  last 
update . 

Concurrency 

The  concurrency  problem  may  arise  when  the  system  allows 
more  than  one  user  to  update  the  data  base  concurrently.  In 
our  particular  system,  concurrency  problems  may  also  arise 
when  more  than  one  user  is  trying  to  ask  questions  about  the 
unit  formation.  In  this  case,  the  working  relation 
FORMATION  is  used  to  contain  the  formation  units.  The 
sequence  of  operations  is  that  the  program  deletes  the 
previous  contents  of  the  relation  FORMATION,  then  starts 
appending  to  it  the  unit  of  the  formation  under  question. 
After  finishing,  the  required  query  will  be  done  upon  the 
relation  FORMATION.  If  another  user  is  trying  to  ask 
questions  about  another  formation  unit,  and  just  after  the 
first  user  finishes  collecting  his  formation  units  into  the 
relation  FORMATION,  second  user  is  trying  to  delete  the 
relation  formation  to  use  it  in  his  query.  If  he  succeeds, 
the  first  user  will  receive  false  results. 

Fortunately,  deleting  the  relation  FORMATION  is  a  kind 
of  update  and  we  will  return  to  the  problems  of  concurrent 
update.  There  are  three  concurrency  problems : 

The  I iO st  Update  Problem . 

The  lost  update  problem  will  a-'oear  when,  for  exanpl 


there  are  two  instructions*  The  first  one  is  to  add  3  guns 
to  Unit  X,  and  the  second  one  is  to  add  4  guns  to  the  same 
unit.  User  A  is  trying  to  add  3  guns  and  user  B  is  trying 
to  add  4  guns  concurrently.  User  A  reads  the  number  of  guns 
of  Unit  X  in  his  buffer  as  10.  Then  user  B  reads  the  number 
of  guns  of  Unit  X  in  his  buffer  as  10.  User  A  adds  3  to  10 
and  writes  the  number  of  guns  as  13.  User  B  adds  4  to  10 
and  writes  the  number  of  guns  as  14.  Finally,  Unit  X  got  14 
guns  instead  of  17. 

The  Uncommitted  Dependency  Problem. 

The  uncommitted  dependency  problem  occurs  when  a 
transaction  reads  updated  data  from  another  transaction 
which  is  not  committed  yet  and  might  rollback.  For  example, 
in  the  previous  example,  if  user  A  adds  3  guns  to  Unit  X  but 
do-  -  .  not  commit  yet,  and  User  B  reads  Unit  X  data  as  13 
gu:  .',  -r  A  rollsback,  then  user  B  adds  4  guns  to  Unit  X 
and  writes  the  sum  as  17  guns  instead  of  14. 

The  Inconsistent  Analysis  Problem. 

Supp.-  •  Unit  Y  has  10  officers,  10  secretaries,  and  20 
technicians.  The  sum  is  40  persons.  User  A  is  asking  about 
the  sum  of  personnel  in  Unit  A,  he  reads  10  officers,  and  10 
secretaries.  Then  User  B  is  trying  to  make  an  upda  in 
Unit  Y.  ii  -  deletes  5  secretaries  and  adds  5  technicians 
(the  sum  should  stay  at  40).  Then  Usei  A  reads  the  number 
of  technicians  as  25  and  ails  the  sum  as  45  instead  of  40. 


Locking . 

A  way  of  solving  the  concurrency  problem  is  through  a 
locking  mechanism.  The  basic  idea  of  locking  is  when  a 
transaction  needs  an  access  on  an  item  in  the  data  base,  it 
acquires  a  lock  on  that  object.  The  effect  of  the  lock  is 
to  prevent  other  transactions  from  accessing  that  object 
before  its  committment  accessing  and  thus  it  prevents  other 
transactions  from  changing  it  or  from  getting  false  data  (in 
case  of  update  then  rollback). 

There  are  two  types  of  locks,  exclusive  locks  (x  locks) 
and  shared  locks  (s  locks) .  X  lock  is  requested  when  the 
transaction  will  update  the  data  base.  S  lock  is  requested 
when  the  transaction  will  only  retrieve  the  data.  Many 
transactions  of  s  lock  may  access  the  same  data  item.  But 
or-.iy  one  transaction  can  access  the  data  item  if  x  lock  is 
r-..  juested  ( i .  •? .  ,  x  lock  can  not  share  any  type  of  look)  .  A 
disadvantage  of  trio  locking  mechanism  is  the  probability  of 
the  deadlock.  This  problem  should  be  handled  by  the  system 
having  the  ability  to  detect  the  deadlock  and  decide  what  to 
d11  to  recover  from  it.  The  whole  concurrency  problem  will 
i,  •  handled  on  the  system  1  •  •  a:.1  we  should  insure  that  the 

able  to  solve  this  problem. 


system  is 


Security 

Security  is  to  protect  the  data  base  against  both 
undesired  modification  or  destruction  of  data  and  against 
unauthorized  reading  of  data  (7:355). 

General  Considerations. 

There  are  some  aspects  to  the  security  problem  that 
should  be  considered: 

-  Legal  and  social  aspects.  For  example,  if  the  user 
asking  about  the  unit  data  has  the  right  to  do  so. 

-  Physical  Control.  For  example,  are  the  computer, 
the  terminal  rooms,  and  the  magnetic  media  locked 
and/or  guarded? 

-  Policy  question.  For  example,  what  is  the  policy  o 
accessing,  i.e.,  who  should  be  allowed  to  access 
what? 

-  Operational  problem.  For  example,  how  are  the 
passwords  that  are  used  kept  secret? 

-  Hardware  control.  For  example,  does  the  CPU 
provide  any  security  feature,  such  as  storage 
protection  keys? 

-  L  ;■  .-‘rating  system  security.  For  ex  j.  ,t.io ,  does  the 
underlying  operating  system  erase  the  contents  of 
storage  and  data  when  it  is  finished? 

(2:238) . 
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View  Mechanism. 


The  view  mechanism  is  an  efficient  way  for  security 
purposes.  We  can  create  a  view  to  a  user  and  the  user  will 
access  the  view  c.  s  if  it  is  a  real  relation.  There  are 
three  ways  for  making  a  view.  First,  a  user  may  see  the 
view  as  a  projection  of  the  original  relation.  For  example, 
tne  transportation  department  needs  only  to  know  which  unit 
is  in  which  location  to  manage  the  transportation  plan,  so 
there  is  no  reason  to  let  its  user  see  unit  percentage  of 
completion  or  instruction  number.  Other  relations  may  not 
be  seen  by  the  user.  For  example,  relations  unit  model, 
persons  and  armament  may  be  hidden  from  the  user  of  the  food 
department . 

Tne  second  type  of  a  view  allows  the  user  to  see  a 
particular  selection  of  the  relation.  For  example,  the 
armor  department  can  see  only  the  units  that  a'-o  supplied  1  . 
armor  personnel.  There  is  no  reason  to  let  the  a:,  or 
department  user  see  the  organization  of  the  navy  units. 

The  th'rd  type  is  a  combination  of  projection  and 
selection  of  da  t  a  in  the  particular  view. 

C' UAMT  and  RKVOK M  danism. 

i.c  view  mechanism  allows  the  data  u.i.->e  to  be 
con  .ept un 1 ly  divided  up  into  pieces  in  various 
ways  so  that  sensitive  inf  n  at  ion  can  be  hidden 
from  u:.  i  ■ !  hor  i  zed  users.  However,  it  does  not 
allow  for  the  specification  of  the  operations 
that  authorized  users  may  execute  against  those 
p i  •  res .  (2:441)  . 


GRANT  and  REVOKE  mechanism  or  the  authorization 


subsystem  can  do  that.  The  system  administrator  has  full 
rights  to  the  data  base.  According  to  the  organization 
policy,  he  can  GRANT  a  user  rights  to  access  certain  pieces 
of  the  data  base  in  a  certain  way.  Some  users  will  have  the 
rights  to  retrieve  the  data  only,  others  may  have  the  rights 
to  update  but  not  to  delete.  Other  users  may  have  rights 
for  full  access  to  a  certain  view. 

Any  authorized  user  who  has  certain  rights  to  access  the 
data  base  can  GRANT  rights  (not  exceeding  his  own  rights)  to 
another  user.  The  second  user  may  again  GRANT  rights  (not 
exceeding  his  own  rights)  to  a  third  user.  The  first  user 
can  REVOKE  the  right  he  or  she  granted  to  the  second  user, 
and  this  operation  REVOKES  automatically  the  rights  of  the 
third  user'.  The  system  should  keep  track  of  the 
authorize1-  ion  subsystem  and  the  system  administrator  should 
check  t th-s  au tho r i za t ion  subsystem  is  running  according 
to  the  organization  policy. 


VIII.  Data  Base  Integrity  and  System  Interfaces 


Data  Base  Integrity 

In  any  designed  data  base  management  system,  there 
should  be  facilities  to  protect  the  data  base  from  both 
incorrect  data  (for  example,  the  unit  percentage  of 
completeness  must  be  between  0  and  100)  and  inconsistent 
data  (for  example  when  inserting  a  new  unit,  the  command 
unit  must  be  an  existing  unit).  These  two  problems  refer  to 
the  integrity  problem.  Integrity  means  protecting  the  data 
oase  against  the  misuse  by  the  authorized  users. 

Integrity  Rules. 

There  are  two  integrity  rul-.-.i  for  the  relational  -idol 
as  mentioned  by  C.  J.  Date  (2): 

1.  Entity  Integrity 

No  attribute  participating  in  the  primary  key  ef  a 
base  relation  is  allowed  to  accept  null  values. 

2.  Referential  Integrity 

If  base  re  la*,  i  m  R2  includes  a  foreign  key  FK 
;■  -ching  the  primary  key  PK  of  some  base  relation  Rl,  then 
every  value  of  FK  in  R2  must  either  (a)  be  equal  to  the 
Valu-  of  PK  in  some  tuple  of  Rl  or  (b)  be  wholly  r.  :  )  1 
ee~.r  ibute  value  participating  in  that  FK  value  must  be 

null).  Rl  and  R2  are  not  neco.;:;  uily  distinct  (2:252). 
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The  second  integrity  rule  is  handled  in  the  application 
program  leve 1 . 

Integrity  in  OMADB. 

Since  OMADB  consists  of  10  relations  and  or  updates  in 
one  relation,  other  relations  may  be  affected.  The  designed 
update  program  EDOMADB  observed  and  handled  the  second 
integrity  rule  carefully. 

Inserting  a  New  Unit. 

When  inserting  a  new  unit,  the  program  starts 
checking  the  entered  unit  code  format  before  calling  the 
data  base.  If  the  syntax  is  correct,  the  program  checks  if 
t.nere  is  any  existing  unit  in  the  data  base  has  the  entered 
code.  Simply  the  system  cannot  allow  two  units  to  have  the 
same  code .  To  keep  the  consistency  between  UNIT  relation 
and  UN  I T  MO  DHL  relation,  the  progrn...  checks  if  the  now  unit 
has  an  existing  unit  mod -el .  If  not ,  -he  user  has  t  insert 
the  required  unit  model  before  updating  UNIT  relation.  The 
prog. asks  the  user  to  enter  the  new  unit  model  data. 

Three  relations  (UNITMODEL,  ASSIGN? ,  and  ASSIGNA)  will  be 
updated  no  insert  the  new  unit  model.  To  keep  the 
c  rectnuss  of  the  unit  mod--!  itself,  the  personnel  data 
1  person  department  and  specialization)  w ;  •  l  be  checked  if 
s.  departments  provide  such  spec ia 1 1 n  i t ion  or  not.  The 
relation  that  keeps  this  inf  or:;;  a  1  ion  is  the  relation  PEkSoh. 
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If  the  department  and  specialization  are  consistent,  the 
data  will  be  accepted  and  a  new  tuple  will  be  added  to  the 
relation  ASSIGNP.  A  similar  test  is  done  when  entering  the 
unit  armament  table.  The  relation  armament  holds  the 
information  about  which  department  supplies  which  arms  or 
equipment,  and  the  program  checks  the  entered  armament  data 
against  this  relation.  If  the  program  insures  that  the  unit 
model  of  the  new  unit  exists,  it  asks  the  user  to  enter  the 
unit  data  to  start  modifying  the  unit  data  which  is  stored 
in  the  relations  UNIT,  PLAN,  and  COMMAND.  An  appropriate 
test  is  done  on  each  unit  data  entered  by  the  user.  The  unit 
percentage  of  completeness  must  be  between  0  and  100.  The 
unit  location  must  be  one  of  the  six  locations  a,  b,  c,  d, 
e,  or  f.  The  unit  plan  must  be  identified  by  PLANID 
re-1  i»  '  v.  5  1  the  command  unit  inur/  be  an  existing  unit.  At 

tills  ;  ...  ,  trie  system  can  respond  trial  th--  new  unit  is 

inserted  and  the  data  base  is  in  a  consistent  state. 

Am  ending  an  Existing  Unit  Data. 

When  amending  a  unit,  the  program,  checks  the 
existence  of  such  a  unit.  The  amended  module  displays  a 
menu  to  th-'  user  for  selecting  an  attribu1'  to  be  amended. 

A  similar  check  as  is  done  in  case  of  inserting  a  new  unit 
ita,  is  done  on  the  amending  data.  Because  the  unit-plan 
relationship  is  many  to  many,  each  tuple  in  PLAN  relation 
b  is  the  information  about  one  plan  for  one  unit.  For  this 


reason,  amending  unit  plan  is  done  through  the  insert/delete 
operation.  The  program  prevents  the  user  from  adding  a  plan 
which  the  unit  has,  and  from  deleting  a  non  existing  plan. 
Modification  is  done  attribute  by  attribute  and  the  user  has 
the  chance  to  re-amend  the  same  attribute  if  he  or  she 
needs.  After  the  modification  of  each  attribute,  the  data 
base  will  be  in  a  consistent  state. 

Deletion  of  Unit(s). 

When  the  user  asks  the  program  to  delete  a  unit, 
the  program  checks  the  existence  of  the  unit  first,  then  it 
starts  checking  if  this  unit  has  another  subunit (s).  This 
check  is  done  by  calling  the  CTREE  module  that  uses  COMMAND 
relation  as  the  source  of  data  and  FORMATION  relation  as  the 
destination  of  the  result  and  other  two  temporary  relations 
SONS,  and  PARENT.  After  execution  of  CTREE  module, 

FORMATION  relation  con*-  ;  i  ns  the  deleted  unit  and  it  , 
subunits  if  any.  The  program  checks  if  formation  relation 
contains  more  than  one  unit  and  asks  the  user  if  he  or  she 
wants  to  delete  all  subunits  or  no*-.  The  program  is  not 
a  1  1  ov:  .'d  to  d^1  •  r  ■-*  a  unit  and  leaving  its  subunit  (s) 
cn  e.'led  by  a  non-existing  unit.  If  the  user  answer  is 
"yes."  ,  the  program  deletes  any  occurrence  of  the  unit(s) 
that  ■■si  st  in  the  relation  FORMATION  from  the  three 
relations  UNIT,  PLAN,  and  COMMAND.  At  this  point,  the  data 
base  is  in  consistent  state. 


System  Interfaces 

Recalling  Figure  1  which  describes  the  integrated 
information  system  for  the  Egyptian  Armed  Forces,  we  will 
observe  that  the  organization  structure  system  has 
interfaces  to  other  systems.  We  will  discuss  these 
interfaces  as  two  types  of  activities,  data  needed  from 
otner  systems,  and  data  needed  for  other  systems. 

Data  Needed  From  Other  System. 

Tne  ten  relations  that  our  system  consists  of  are  not 
basic  system  relations.  Some  of  these  relations  may  be  a 
view  of  a  relation  created  and  manipulated  by  another 
system.  One  reason  for  the  integrated  information  system  is 
to  keep  the  data  integrity  over  all  organizations  in  the 


armed  force  and  consequently  in  all  information  system.  The 
A R NT  relation,  which  could  be  a  vi-v;  of  another 
relation,  which  contains  more  information  about  armament  in 
the  material  support  system. 

ARMAMENT  relation  (or  view)  may  give  us  an  answer  of  a 
question  that  the  organization  stru".  are  alone  is  not  able 
to  an  .  ■  r .  What  armaments  exist  in  department  X  (or  in  the 
arm-vi  forces)  that  is  not  used  by  any  unit.  The  answer  :r 
this  query  gives  us  the  most  recen*-  ^ypes  of  armament  that 
is  not  yet  used  by  any  unit,  an  :  also  gives  us  the  obsolete 
type  that  is  out  of  service  and  the  department  did  not  get 
rid  of  yet.  A  different  question  may  arise,  and  that  is 


whether  the  material  support  system  allows  the  organization 
structure  system  to  retrieve  this  information.  If  not,  how 
will  a  new  unit  that  will  use  a  new  type  of  weapons  be 
inserted  to  the  data  base  without  the  conflict  of  the  non- 
existance  of  the  new  type  of  weapons  in  ARMAMENT  relation? 
Again,  the  view  system  should  be  studied  carefully. 
Similarly,  PERSON  relation  may  be  a  view  of  another  relation 
in  the  Personnel  System,  and  PLANID  relation  may  be  a  view 
of  another  relation  in  Command  and  Control  System.  For  that 
reason,  editing  of  the  relations  PERSON,  ARMAMENT,  and  PLAN 
is  not  mentioned  in  the  EDOMADB  program.  To  let  the  system 
work,  and  until  establishing  the  interfaces  to  other 
systems,  editing  of  the  mentioned  three  relations  will  be 
done  by  separate  programs  and  we  will  let  that  be  done  by 
users  representing  Personnel  Material  Support,  and  Command 
and  Cor. t-'  •!  Systems. 

Unit  percentage  of  completeness,  location,  and  plan  are 
amended  oy  operational  instruction.  The  unit  is  created 
with  these  three  attributes  by  our  system.  Amending  these 
d'  Tibutei  should  be  done  through  the  comma r  1  and  control 
syshui  (or  its  representative  user  for  the  time  being)  and 
it  should  have  the  right  to  amend  percentage  and  location  in 
UNIT  relation  (only  amend,  not  delete  or  insert)  and  should 
hav-  full  access  to  PLAN  relation. 


Data  Needed  for  Other  Systems. 

The  organization  structure  system  is  able  to  provide  the 
other  systems  useful  data.  For  example,  the  command  and 
control  system  needs  to  know  information  about  the  command 
relationship  between  units;  also,  other  unit  information  is 
needed  for  the  command  and  control  system.  UNIT,  COMMAND, 
ASSIGN?,  and  ASSIGNA  relations  may  be  seen  by  command  and 
control  system.  UNIT,  ASSIGMP,  COMMAND  may  be  seen  by 
Personnel  Systems.  UNIT,  ASSIGNA,  COMMAND  may  be  seen  by 
Material  Support  System.  The  Finance  System  may  need 
information  about  number  of  units,  total  number  of  personnel 
for  each  specification  and/or  for  each  department,  and  may 
need  some  information  aoout  unit  armaments.  Interfaces 
between  systems/ subsystems  should  be  identified  to  keep  the 
overall  system  integrity. 


IX.  Conclusions  and  Recommendations 


The  integrated  information  system  of  the  Egyptian  Armed 
Force  consists  of  two  main  systems,  Command  and  Control 
System  and  the  Logistic  Support  System.  The  Logistic 
Support  System  consists  of  four  main  systems,  Organization 
Structure  System,  Material  Support  System,  Personnel  System, 
and  Finance  System.  The  integrated  information  system  must 
not  be  designed  and  implemented  all  at  the  same  time.  A 
better  way  is  to  design  and  implement  system  by  system  anc 
subsystem  by  subsystem  keeping  in  mind  the  design  con¬ 
siderate.. n,  the  system  (or  subsystem)  interfaces,  and  the 
overall  data  base  integrity.  This  projects  presents  a 
design  m  ;  1  and  a  methodology  that  may  be  followed  in  other 
systems  and  subsystems.  One  way  of  dot:  i  that  is  to  assign 
the  mission  of  the  system  integration  to  an  organization 
(maybe  information  systems  department).  This  organization 
designs  the  over  all  system  design,  determines  the  design 
considerations  for  each  system  and  subsystem,  and  sets  the 
required  specification  for  each  system  an.',  subsystem.  Once 
the  overall  design  is  done,  design  and  implementation  of 
each  sy.:  ‘  »-:n  and  subsystem  should  be  assigned  to  an  f-med 
force  organization  taking  into  consideration  the  required 
personnel,  training,  and  finance.  To  keep  the  integrated 


information  system  homogeneous,  the  system  integrator  should 
choose  the  proper  DBMS  model  that  will  be  used  in  all 
systems  and  subsystems.  (This  project  choose  the  relational 
data  base  model  for  the  considerations  mentioned  in  Chapter 
V) .  The  needed  software  and  hardware  should  be  estimated 
early  oy  information  system  departments  for  the  entire 
integrated  information  system.  The  signal  corp  department 
may  carry  the  mission  of  design  and  implementation  of  the 
data  communication  needed  for  the  integrated  system. 

Four  problems  should  be  handled  carefully  over  all  the 
system  and  subsystem. 

1.  Recovery  from  failure 

2.  Concurrency 

2 .  System  security 

4.  Data  integrity 

Again,  sys  t  ■ '  suosvs  t  o: .  interfaces  should  be  identified 
clearly  and  carefully. 

This  thesis  effort  contributes  to  building  the  Egyptian 
Armed  Force  integrated  information  system.  Design  and 
implementation  of  other  system/sub system  in  the  integrated 
information  system  may  follow  the  same  methodology  as  used 
i . .  this  work. 
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rsicn  : 
T  L  £  : 

L  £  NAM: 
FT  H  A  R  E 
£  :  To 
an  i 

NT  ENTS 
C  T  I  C  N 


7  MAY 
1.0 
COLL: 
:  TRE 
SYSTEM 
c  o 1 lec 
t . 

:  ann 


19  8  6 


CT  UNIT  TREE 


:  UNIX 

t  units  t  n  a  t  is  commanded  ie  /  a  particular 

♦  get_unit_code*  checkunit,ctrea. 

Accsot  unit  code  from  the  terminal 
Check  the  unit  code 

disolay  error  message  if  the  code  is  wrong  or 
the  unit  is  not  exist. 

If  tne  coder  is  correct  delete  the  relation  FORMATION 
ana  using  tna  two  te moorary  relations  PARENT  and  SONS 
append  to  tne  relation  FORMATION  the  unit  code  and  th 
all  its  subunit(s)  code(s). 


p.  u.  »•»  «>.  .u  «•#  u.  »'»  u.  a.  »•»  %»#  «•»  »v  %'*  «<<  j.  «*«  rL  u.  •*.  *'#  e.  .■<  *v»  u.  »*#  «<»  .i.  u.  »•»  v'«  *■»  u»  »■»  .<>  u.  p.  «u  v.  *•*  •*«  »w  / 

...  v  *.•  -i*  v  «.*  i*  v  *.*  *.»  *.*  v  *i*  -I*  *.•  «i»  v  •,*  ».»  *■'  v  *i»  *.*  *i»  v*»  *i*  m  •,»  •<*  v  V  *«»  *(•  n*  •*  »>»  *r  v  "r  *.*  'i*  i*  •>»  *,«  / 


VERSION  :  1 . : 

M  0  0  u  L  :  N  u  M  3  E  R 
MODULE  NAME 
FUNCTION 
ALGORITHM 


Inputs  : 

OUTPUTS  : 

S  L  0  A  L  V  A  R  I  A  3  L  E 
j  L  0  j  A  L  VARIABLE 
" I L : S  READ 
=  ILES  WRITTEN 

hardware  i \jj; 

HAROWARE  OUTPUT 
CALLED  modules 
I.  ILL  INS  MODULES 
A  JTMER 
HISTOR  r 


Collect  Formation's  units  through  a  root 

1  -  call  get_unit_ccde 

2  -  call  checkunit 

3  -  call  ctree  function  to  collect  the  unit  t r 

into  the  relation  FORMATION 

none 

error  m-jsseres. 


READ 

Changed 


x  cl  e  p  »  xlevel*  xtype*  x  n  u  m 


get_unit_codeC)t  cnec*<unit()»  ctreeC). 
none 

LT  COL  G  A  i  £  •:  A.  ELSHARAWY 

Version  1.0  by  Lt  Col  Saber  A.  r 1 s n a r a w y 
AFIT/EN  GC  5  £6J  7  MAY 


♦include  <  ;  i  ,  .  > 
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■i  #  char  x  d  e  p  C  3  3  »  x  1  a  v  e  1  C  3  3  *  x  t  y  p  e  C  3  3  »  x  nu  t  C  4  3  ; 

■na in C  ) 

extern  char  x  d  a  p  C 3  %  x  1  e  v  a  1  C  3  *  x  t  y  p  e  C  3  *  x  n  un  C  3 
{ 

int  c oun t » nu n_un 1 1 s  ; 
ge  t_unit_codeC  )  5 
printfC"  Calling  ingres  \n"); 

*  *  ingres  omadb 

printfC"  Jn  it  check  :  " )  .* 
if  (chackunitO  =  =  0) 

{ 

printfC" T n is  unit  is  not  exist  ..  try  again  \n") 

> 

else 

{ 

printfC  "Pass  e  cl  \  n  "  )  ! 
nuT_units  =  ctreeC); 
l f  Cnun_units  ==  1  ) 

< 

printfC" This  relation  contains  one  tuoieNn"  )J 


II  1.2 


JAT  = 
t  =  R  S  :  0 ;» 
MJCjlE  U 
\  -  j  i  L  E 
-UNCTI 
A  L  J  0  S’  I  T 1 


INPUTS 
:  ' J  T  P  u  T  s 
j  L  D  3  -  L  V 
3  L  j  5  A  L  V 

*  i  -  J  - 

-  I  f  :  S  «  k 
iARD.,A9E 
-*APC«APE 
CALL  E  2 
CALL!',  j 
A  J  T  H  c  ? 
hi  STOP  Y 


:  7  ’’ A  Y  19  33 

:  i . : 

J  M 3  E  P  :  1.2 

A  M  £  :  c  n  e  c  <  u  C  ) 

:  check  t  n  e  unit  c  o  d  e  C  d  e  o  »  1  a  v  e  1 » 
v  :  1  -  if  tne  unit  code  exist  in 

returnCl ) 

2  -  if  not  returnCO). 

:  none 
:  0  or  1 

A  r  I  A  3  L  E  READ  :  xdepj  x 1 e  v  e 1  *  xnun 

A  I  ' 3  L  E  CHADDED  :  none 
A  C  :  none 

I  T  T  E  •'  non-; 

I *  j  T  :  none 
0  .  r  '  ■ 1 7 :  none 
J  D  .  L  E  D  :  ti  f  i  n  C  ) 

:-1  D  j  .>  L  E  S  :  none 

:  LT  COL  DA?--,  j.  ELShAPAUY 
:  Version  1.0  by  L  t  Col  Da  bar 
A  r I T / E  N  DCS  3  6 J  7  MAY  1936 


type*n„-). 

the  relation  UNIT 


E  1  s  h  a ' 


-  k  u  n  1 1  C  ) 

extern  c  h  a  - 

c  n  a  r  t  c!  a  c  C  •  :  , 

1  •  1  .  x  I  jl[],xty3aC] 

1 1  ■  j  }  1  C <  1  .  ttypeC31. 

May 

22  10:49  1936 

tree. a  Page  3 

*  a  r 

etrieveCtdeo  = 

u.dep*  tie 

v  e  1  - 

a  a 

tnun  = 

u  .  n  u  m  ) 

*  a 

anere 

u.dep  = 

x  d  e  p 

a  a 

a  n  cl 

u. level  = 

x  1  e  v  e  1 

a  * 

and 

u  .  ty oe  = 

x  t  y  o  a 

*  9 

an  cl 

u  .  n  u  Hi  - 

x  nu  m 

I.  1  JV3ll  ttype  =  U.t/c 


if  (  s  trcmpC  xciap  *  tdep)  -  =  0 
ED  strcmpCxievel,  1 1  v  a  1 )  =  = 
EE  strcmpCxtypa  *  ttyp?)  ==  0 
EE  s t rc mo C x n un *  tnum)  *  =  0) 

{ 

r  3  torn  C 1 ) * 

> 

3  i  S  3 
{ 

return(O)  J 
) 


/*  II  1.3  main 

/  * - 

DATE  :  7  MAY 
VERS ION  :  1.0 
M  C  0  U L  £  NUMBER  ’ 
M 0  0  j  L  E  NAME  : 
=  u4Ct:dn  : 

A  LGC?  I  7-1-1  : 


:\3jTj  : 

!  j  t  ?  u  t  s  : 

Global  variable 
,ldbal  variant.  - 
:  I  L  E  S  READ  : 

:  I  L  E  S  R  r  I  T  T  E  N  : 
(  A  R  D  «  A  R  =  I N  =>  U  T 
1AR0RARE  OUTPUT 
:  ALL  ED  MC GULES 
*  L  L  I  N  G  MODULES 

•  'HER 

•  TORY 


t  / 

1  9  S  6 
1.3 

ctre  e(  ) 

Collect  formation's  unit  through  a  root. 

1  -  Create  ti?  tjisDorary  rjlation  PARENT 

0  -  Create  t  n  e  t  ;:noorary  raiation  SDNS 

3  -  Delete  t h e  contents  of  t  n  e  relation  -ORMATIJN 
•»  -  Apoend  to  3  A  R  E  N  T  t’s  c  o  m  n  a  n  ;!  unit  (  *  r  o  r. 

tnj  global  variables*  xcieo*xl?vel*xtyD?*xnun) 

5  -  Append  to  SJ.\3  unit  trot  is  commanded  d  i  r  e  c  1 1  y 

by  any  unit  in  P A R E NT ( u s  .  n  „  :  -  ?  relation  C0MMA' 

6  -  Appenci  to  “ 0 R M A T 1 0 N  all  units  in  PARENT. 

7  -  Delete  the  contents  of  PARENT. 

3  -  If  number  of  units  in  SONS  <  1  then  EXIT 
else  continue. 

9  -  Append  to  Parent  all  units  in  SONS. 

10-  Delete  tne  contents  of  SDNS 

11-  Go  to  step  5 

12-  Destroy  SONS*  destroy  PARENT*  exit. 

Root  unit  code 

The  raiation  FORMATION 
READ  !  x  d e  p  *  x  level*  xtyp’i  x  n  u  m 

r h A  N  G  E  D  !  none 
none 
none 
none 
none 


LT  COL  GASER  A.  E  t  S  H  A  -  .  .  • 

Version  1 . C  by  Lt  Col  Sauer  A.  Elshnrajy 
AFIT/5N  CCS  S  S  J  7  MAY  19S6 
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C  t  r  e  e  (  ) 

{ 

/$  ««8xtarn  char  x  d  9  p  «  x  1  a  v  a  1  •  x  t  y  p  a  *  x  nu  n  $/ 


nt  flag* 

f  1 ,  f  2  ,  f  3  ,  f  4  ; 

*  * 

create 

parent!  cl  ep=  c2*level 

=  c2*type=  c2 

*  n  u  ,n  =  c  3  ) 

4  4 

create 

sons(dep=  c2*level 

*  c2  *  type^  c  2 

*num=  c3) 

4  9 

range 

o  f 

p  is  parent 

4  9 

r  an  g  a 

o  f 

s  is  sons 

9  9 

range 

0  f 

f  is  formation 

9  9 

range 

0  f 

c  is  c  on  "h  a  n  d 

5  a 

delete 

f 

t  a 

a  o  p  e  r  cf 

to 

parent! dep  =  xdep 

*level  =  xlevei*tyoe  = 

4  9 

nun  = 

x  n  u  n  ) 

o 

{ 

9  9 

append 

t  0 

sons!  cl  30  =  c.dep, 

level=  c.leve 

1  *  ty pe  =  c 

a  a 

n  u  n  =  c  . 

nun) 

9  4 

jhera  c.cdeo  = 

o  •  d  e  o 

a  a 

a.nci  c.clevel 

=  p. level 

a  a 

and  c.ctype 

=  p.tyDe 

1  5 

and  c . c  n  u  m 

=  o  .  n  u  T 

a  a 

append 

t  0 

for  nation  Cp.all) 

*  a 

delete 

p 

i  a 

retrieve 

(flag  =  countCs.de 

o)  ) 

x  ty  pe  * 


typ  3  * 


.ag  <  1 ) 


if  < 

< 

d  r  i  n  t  f  C  "  3  1  a  t . 
> 


.on  =  2x.MATIuN(cido*levelttyDe*nun)  is  created  \  n " ) 


*  ? 
*  * 


{ 

accr.:! 

cl  3  1  e  t  a 

> 


parent  (  s  .  a  1 1  ) 


■jhile  C  f  1 


*  a 

*  ? 
*  < 


retrieve 
retrieve  (  f  2  = 
retrieve  (f3  = 
retrieve  (  f  4  = 
destroy  parent 
destroy  sons 
if ( f 1  >  1  ||  f 2 

return(2)5 
els  e 

retjmCD! 


>  o ) ; 

Cfl  =  c oun t ( f . d e o  )  ) 

count (f. level)) 
ccunt(f.type)) 
count ( f . nvn)  ) 


>  1  ||  f  3  >  1  II  f  4  >  1 ) 


} 

/: 


/*  ||  1.1  get_unit_c ode 


DATE  :  7  •!  4 1 

19  5  5 

7  :  ?  j  !  1  ■*!  :  1.0 

M  N  U  M  5  E  R  : 

1.0 

MlllLE  NAME  t 

get_v.ni  >  _coc; 

eC  ) 

r'JNC  •  .  .1 

A  c  •  .  n  1 1 

code  r  r o  n  usjr 

-  1  -  L 

All'.  : 

\  -  Display 

itiesse;-'  to  le‘  T 

-  w  .»  i  r 

t  n  e  unit  d  a  t  ?.  (  x  nl..w 


t  y  p 


.  syntax 
:  er 

O 


■lay  2  2  19:49  19  8  6  traa.q  0  a  g  e  5 


INPUTS  : 

OUTPUTS  : 

3L  93  AL  VARIABLE 
GLOBAL  VARIABLE 
=  ILE$  READ 
=  IL£S  *  R  I  T  T  E  N 
HARDWARE  INPUT 
-lARDrtAR;  OUTPUT 
CALLED  M  9 D U  L  E  S 

: all i mg  M soul  eg 

A  u  T  H  c  R 
Hi STCR  Y 


2  -  Acceot  the  user  input 

3  -  Check  the  syntax  of  the  usre  input 

4  -  If  correct  exit 

5  -  If  not  request  the  user  to  reinput  the  data 

or  quit. 

user  input(xdeD,xlev?l»xtype*xnuiO 

Messages 

READ  :  none 

CHANGED  :  x  ci  e  p  »  xlevelt  xtyp?»  xnu-n. 

:  none 
:  none 
:  none 
:  none 
:  nein(  ) 

:  none 

:  LT  COL  GA3ER  -  .  ELSrARAWY 

Version  1.0  by  Lt  Col  Saber  A.  Elsharajjy 
A=IT/=N  GCS  soJ  7  MAY  1936 


;et_unit_co:ie(  9 
( 

/-extern  char  xdepCC*xlevelC3»xtypeCC»xnu'nC3-/ 

;  n  t  r  ?  ’  n  t  ■  r  ; 

cl  o 
{ 

printfC"deoe.  rt'Tient  =>  "); 
scanf("^s"»xdeo); 

3rintf("\n")  I 

orintfC" level  ======>  "  9  ! 

s  o  a  n  f  (  "  s  ”  ,  x  1  e  v  j  1 )  ; 

OrintfC" Nr  "9  5 

print  fC'tyee  =  =  =  =  =  =  =  >  "  9  ; 

s  c  a  r,  f  (  "  %  s  "  f  x  t  y  p  e  )  • 

orintf ("\n")J 

printfC" number  =  =  =  =  =  >  " 

scsnx'C"  is'SxnuT)  ; 

printfC "\n")  : 

if  CCstrlenCx;  ;p)  !=  2)  II  CstrlanCxl.-vel)  !=  2)  II 

( s t r 1 en C x t /p e )  !=  29  II  (strlenCxnun)  !=  3)9 

C 

reenter  =  Q  ; 

orintf("The  key  forci.-.t  j  should  be  c2»  c2»  c2»  c3  \n"9 
d  r  i  "  To  exit  print  1  \n"95 

if  C  x  d  e  p  C  0  9  ==  '  I  '  9 
{ 

a  x  i  t  C  1  9  ; 

> 

> 


r  e  1  ■  t  e  r  =  1  ; 

> 


r  ;  r  ' 


1  -  id; 
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Script  started  on  Mon  May  5  22:06:33  1936 
{  tree 

deoartment  =>  999 
level  ======>  10 

type  =======>  HO 

nunoer  ===-->  l 1 

The  key  for. rate  snould  be  c  2  t  c  2  »  c  2  »  c3 
To  exit  print  0 
department  =>  99 

level  ======>  33 

type  =======>  77 

number  =====>  666 

Callin';  inures 

jnit  check  :  there  is  no  such  n y i t  ..  try 


i  tree 

department  =>  10 

level  ======>  05 

TyOe  =  =  =  =  =  =  r>  02 

number  ===-->  10C 


Calling  l"/^ 

Unit  creek  :  Massed 

delation  rQ3M4TI3N(dep»level,type>num )  is 
K  i  n  g  r  e  i  o  m  a  d  b 

I  \  j  x  £  S  version  7.10  (10/27/31)  login 
•Ion  May  5  2  2  :  1  0:  5  7  19  36 
go 

print  fon1  ’  *.ion 
■:=  ^5 

executing  .  .  . 


fornation  relation 


Idea 

1  — _ 

I  level 

1  type 

1  nu  n 

110 

105 

102 

mm 

I  to 

1  0  5 

103 

1010 

!  10 

106 

103 

1011 

1  1  1 

1  06 

107 

1  100 

;  o  ”  t  1  •*  ■  i  "> 

\  0 

Z'iZlz  5  V  •  no  7.10  (  1  0/2  7  f 


again 


create 
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Mon  May  5  22 514553  1936 
g  o  o  ci  b  y  a  gsharauiy  --  come  again 
v„  tn?e 


deoartment 

=  > 

1  1 

level  ===== 

=  =  > 

06 

type  ====== 

=  =  > 

0  7 

number  ==== 

=  =  > 

100 

Calling  Ingres 
Unit  c " ? c k  5  P  a  s  s  a  c 

halation  F3RMATi3N(dep»lavel*type»num)  is  created 
Tnis  relation  contains  ona  tuple 
X  Ingres  o m a d !j 

INGRES  version  7.10  (10/27/31)  login 
•Ion  May  5  22  5  1  9  5  1  0  1  9  36 
go 

S  print  formation 

J.  V  ~ 

-  'a 

Executing  .  .  . 


formation  relation 


I  1 e  v a  1  I  t  y  p  9  I  n  u  m  I 


111  106  107  1100 

| - 


continue 
*  \a 

INGRES  version  7.10  (10/27/31)  logout 
Mon  May  5  22520503  1936 
goodbye  g  s  M  a  r  a  ui  y  —  come  again 
i 

script  done  on  Mon  May  5  22520503  1956 
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Script  started  on  T  u  e  May  6  2  0  :  2  0  :  5  3  19 

X  tree 

Jeoartnent  =>  10 

level  ======>  05 

type  =======>  02 

o  u  vi}  3 r  =  =  =  =  =  >  100 

Calling  in -res 
Unit  cneck  :  Passed 

delation  FCP^iTIDUCdap, level »type*num)  l 
i  l  n  ;  n  &  s  o •* a d b 

: \ G  9  =  S  version  7.10  Cl  0/27/31)  login 
T  u  a  May  6  20:25:52  1936 
;  o 

s  print  for. nation 
* 

executing  .  .  . 

f  o  r  t  ;•  t  i  o  n  relation 


ci  ep 

I  1  e  v  e  1 

1  typ  e 

|  nun 

1  0 

105 

102 

1100 

* 

*  ^ 

1  0b 

103 

1  01  0 

1  0 

1  0  6 

103 

1011 

1  1 

I  0  6 

i  e? 

1100 

continue 

'•s  print  assign? 

■s  \  g 

executing  .  .  . 


assignp  relate  ' 

I  :!  ?  o  |  1  e  v  i  1  |tyoe 


pdep  Ispec  |  n  u  t 


> 


User  Manual  for  the  Edit  Program 


Introduction 

This  manual  contains  a  brief  introduction  on  how  to  use 
the  edit  program  OMAED  to  edit  the  data  base  CMADB .  It  does 
not  go  into  a  lot  of  detail  about  the  program  design  or  data 
case  features,  but  tries  to  give  enough  information  to  get  a 
user  to  use  the  system.  After  reviewing  this  manual,  the 
user  should  have  enough  information  to  deal  with  the  editing 
pro  ;  r  in  OMAED .  The  manual  is  divided  into  four  sections. 
Eucn  so-'*  ion  describes  an  operation  the  program  can  perform 
(!'■•*  r  iev- ■ ,  D*.*  1  *  •  ,  Amend,  and  Insert).  To  get  the  program 
started,  just  typ*-  OMAED  and  hit  return,  the  program  will 
-> a  r  '  /  display  i :  ;  "da  !  1  : :  :  Ingres",  then  the  following 

1  i  be  display-.-  i  with  a  command  summary 

Amending  Units  Data. 

Command  Summary. 

I  . Insert  new  unit. 

D . Del  •  an  existing  unit. 

A . Amend  an  existing  unit. 

R  .  Retrieve  an  existing  unit. 

II  . Hein  (display  commv',  summary). 

E . Exit  to  UNIX. 

The  program  can  accept  •  o. . an. in  lower  or  upper 


120 


case  characters.  "H"  command  displays  the  command  summary 

i 

menu.  Nov;  you  can  select  the  required  operations  by 
entering  the  corresponding  command.  After  finishing  the 
edit,  type  "e"  to  exit  to  UNIX. 

Retrieve  Unit  Data 

To  retrieve  unit  data,  type  "R"  and  hit  return.  The 
program  will  ask  you  to  enter  unit  key  (dep,  level,  type, 
nun)  and  will  check  the  syntax.  If  not  correct,  you  will 
see  the  message  "the  key  format  should  be  C2,  C2,  C2,  C3." 
I:  tno  unit  does  not  exist  in  the  data  base,  you  will  see 
mossa  ;e  "Tars  unit  does  not  exist."  If  the  key  is 
correct,  the  system  will  print  on  the  screen  the  required 

•1»  unit  cats  (unit  name,  unit  location,  instruction  number, 

If 

...it  o-i  lance,  percentac-  • ,  numoer  of  pe  rsor.n.  •  1  ,  command  unit 


coae,  an;  ur it  plan ( s ) ) .  in  •  program  will  return  after  that 
to  tne  u  t an:  mode. 

Deleting  a  Unit(s)  From  the  Data  Base 

To  d-  .  1  a  unit  type  "D",  the  progr  -  -  will  ask  you  to 


enter  the  unit  key.  If  the  unit  Joes  not  exist,  the  program 
will  print  "This  unit  does  not  exist."  The  program  will  ask 
you  "Are  yr  ;  sure  (Y to  give  you  a  chance  to  quit.  If 
you  type  any  character  rather  :: —  "Y",  the  program  will 
return  to  the  co.ckind  mod-.-.  If  you  type  "Y",  the 
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program  will  delete  the  unit.  If  the  unit  has  another 
subunit,  the  prograin  will  ask  you  "Do  you  want  to  delete 
all  subunits  (Y/N)."  If  you  type  "Y"  the  program  will 
delete  the  unit  and  all  its  subunits. 

Amending  Unit  Data 

To  amend  unit  data  type  "A"  from  the  command  node,  the 
program,  will  display  the  following  menu: 

Modification  Codes . 

Modify  unit  percentage  .  .  .  t 

Modify  unit  location  ...  1 

Meaify  unit  plan . p 

Modify  command  unit  .  .  .  .  c 

Modify  instruct  ion  number.  .  i 
End  of  Mod  if icat ion  .  .  .  .  e 

Again  t : .  -  program  w  ill  accept  b  ,  *  n  low  •  m.  ;  up;,-  :  case 
letters  as  mod  if  icat  ion  cod-1:; .  Select  the  required 
modification  code  and  type  it.  The  program  will  ask  you  to 
enter  the  new  unit  attribute.  After  entering  the  new  value 
t * . program  will  check  it  b  •  : •  :  u  r  *a-.‘  i  *-  is  in  the 
permissible  va 1  ;  ■  domain,  if  it  is  not  _  root,  you  will 
re  ■  v,  an  error  message.  After  e  :  :  a::i->nd,  the  program 

■will  ask  you  to  enter  another  n  od  L  f  icat  ion  code,  when  you 
finish  modification  type  "e"  or  "E"  to  return  to  the  cotnman 


Inserting  a  New  Unit 


To  insert  a  new  unit  type  "i"  or"I",  the  system  will  ask. 
you  to  enter  tne  new  unit  code.  If  this  unit  already 
exists,  you  will  see  the  message  "This  unit  already  exists." 
If  the  new  unit  has  an  existing  unit  model  in  the  data  base, 
tne  program  will  ask  you  to  enter  the  unit  data  (percentage, 
location,  instruction  number,  plan(s),  and  command  unit). 

Checks  will  be  done  on  unit  data  and  an  error  message  is 
displayed  if  the  check  is  not  passed.  If  the  unit  has  r.o 
unit  model  in  the  data  base,  the  program  will  ask  you  "Do 
you  want  to  insert  a  new  unit  model  (Y/N)".  This  is  a 
chance  to  quit  if  you  mistype.;:  the  unit  code.  If  you  type 
the  prijram  will  ask  you  r;  enter  the  following  unit 
m  data: 

-  Unit  r.um ■■ 

-  korson:.-;  data  (  :■  :  :  tx-x.f  ,  s:  cialitv,  number) 

(  r->  :  e:h  --ri  :.  u  r.  ...  ’  ;  type  j  . 

-  Armament  data  (u  •;  ■  :.i,  arm.  nar.-j ,  nuaber) 

(to  end  entering  armament  data  type 

J..ech  >  will  be  done  on  unit  nml-'l  i.-m  -  ..mi  an  tor 
-•usage  is  u  1  splayed  if  the  ch  •  ••  1..  not  passed.  Af  ter 

enter  i .  •  unit  model  data,  the  program  will  ask  you  to 

enter  t  :  unit  data  as  described  above,  then  the  program 

will  return,  to  the  •  mode. 


’  1 3 


Appendix  G 

Computer  Program  for  Editing  the  Data  Base 
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G  D  =  THE  EGYPTIAN 

ARMED  FDRC5S 

I2ATIDN  STRUCTURE 

DATA  EASE 

.  ELSHARAWY 

AFIT/EM  GCS  S5J 

-  ■■/ 

DATE 

:  7  MAY  1936 

/  c  R  $  a.  C  N 

:  1.0 

t:  tl  e 

:  EDIT  CHADS 

-IiE  ‘.AM 

E  :  DMAED.Q 

SYSTEM  :  UN 

J  G  E  :  To 

ecut  tne  Do 

:cnt 


:rain,  m  e  n  u  e  ,  get_unit_code,  checkunit,  insert, 
check_unit_ model,  insert_unit_model»  insert.persjn, 
cieck.parson,  msert_arm,  c^ack_a''m,  insart.Dl-m, 
cnec<_pl3nid»  a  m  m  e  n  d  ,  .modify_commancl,  ir  o  cl  i  f  y  _  o  1  a  n  , 
cnack_plan,  moclify_Dercent»  ■npaify_lo:?tion, 
ntnfh  fa  i  .  rs  tfi  dua  .  .ij  1  j  ♦  »  .  r.  t  »*  p  >  . 


L  i  ~  v  rs  u  i  u  i  i  x  ki  f  n  n  c  i  i  |  .M  v  a.  i  7 

cnack_plan,  moclif  y_D?rcant»  m 
m  o  d  i  f  y  _  i  n  s  t »  retrieval  :i  ?  1  a  t 1 


nod: 
1  - 


Display  c  0  si-n  a  n  cl  su.nnery 
accept  input  ccnm?nd(I,D,A,R,-i,or  E  ) 
accept  unit  code  'r  r  fee*  terminal 
Ceack  the  unit  code 
Call  a  suita bis  rodcla 

ci  a  s  o  1  a  y  error  t?s:-  ;  ;e  it  the  code  is  iron;  or 
if  t  r,  a  operation  is  inconsist  a  nse  jj  i  t  r  the  unit 
statusCexist/not  exist) 

After  performing  tne  operation,  return  to  c  o  m  m  ?  n  < 


0  main 

:  7  MAY 
:  1.0 
J  V  3  £  R  : 


main 

call  ingres,  display  command  summery, 
accept  the  user  comm 3rd,  check  i t ,  a  n o 
call  a  suitable  module. 

1  -  declear  external  variables 

2  -  call  Ingres 

3  -  display  command  Summery 
<♦  -  acceot  tne  user  command 

5  -  if  tne  command  is  not  correct 

display  an  error  message  and 
go  to  s  t .  i 

6  -  if  t  ">  e  command  is  d,D,r,R,i,T, 

a  ,  or  A  ,  call  g e  t  _ u r  i  t  -  •>  ->  e 
and  then  call  check  • ;  n  t  cod.*. 
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1 0 -  go  to 

INPUTS 

user  conn 

outputs  : 

messages 

SLOSAl  variable 

READ  : 

SLOoAL  VARIA3L5 

CHANGED  ; 

PILES  read  : 

none 

=  IlES  wPITTEN  : 

none 

HARDWARE  INPUT 

:  none 

iA  RCA  ARE  3  J  T  ?  U  T 

:  none 

IALLE0  H00JLE5 

CALLING  HCDULES 

:  none 

A  U  T  -  E  R 

:  LT  CCL 

HISTORY 

:  Version 

3  -  if  t  n  e  unit  status  is  consistence  u  i  t  n 
the  oosratin,  call  t  n  e  required  nodule 
9  -  if  not  print  an  error  message 


none 

none 


•  A.  ELSrARA*Y 

Py  Lt  Col  Galeer  A.  E  1  s  h a r  a  u  y 


'include  <stdio.n> 

>  d  j  f  i  n  ■  true  1 

*  .i  e  f  i  n  e  false  0 

c  n  a  r  xdecC30»xievelC33»xtypeC33»xnumC43; 

»;  c  >  a  r  /deoI?C*ylevelC3j»ytyCsC33»ynu-T'C4D; 

*  '  era-  *  p  1  a  n  C  2  3  ,  xpdeoC33»  xscecC43,xadeoCi3 
s=*  era-  recces  t  C  2  3  ; 

*  *  l  n  t  state,  x  n  u  n  p  ,  x  n  u  "  a  ; 


■  C  3  1  □  S 


''  a  l  n  C  } 

{ 

?  x  t  e  r  n  c  "  a  r  x  d 


fxlevelCj* 


-  C  1  ,  x  n 1 


extern  char  ydapCj»ylevalCj*yt/.jeC3,ynu'nC3; 
extern  char  xplanC3fxpcieoC),*scecC3*xadapC3»X! 
extern  char  requestCl; 
extern  mt  state,  xnump,  xnuna; 
in  t  quit; 

orintfC" Calling  ingresNn"  )  ; 

*  *  in,r.-s  orach 

request! -j  =  '  n  '  ; 

requestCll  =  '  \ 0  '  * 

quit  =  false; 


suite-  '.  “nquestCOO) 

{ 

case  '  i  '  I 

case  'I'  :  ifCstate  ==  true) 

printf("Tnis  unit  is  already  existVn") 
else 

insert!); 

hr  e  o '<  ; 

case  ' '  : 

case  '  0  '  :  if  C  s  t  '  *  e  =  =  f  a  1  -  O 

p  -  i  i  >  t  f  C  "  T  n  i  is  not  e  x  i  s  *  ' .  n  "  )  : 
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CclsJ 

case 


case 

case 


'r  '  : 
•  *  • 


w  -  3  £ 

c  c  3  e 


case 

case 


e  r  ?  j  1 1 


cieleteC); 

break; 

ifCstate  ==  false) 

pfintf  (  11  Tns  unit  is  not  eust\n"); 
else 

aumancK  ); 
o  r  a  a  <  ; 

if ( state  ==  false) 

printf  ("This  unit  is  not  existin'1 ); 
else 

retrieveC); 
e  r  a  a  <  ; 

inueO! 
b  r  e  a  <  J 

quit  =  true; 
areak ; 
br  e  ak  ; 

ormtfC"  unr*  cognise  o  input  ..  type  h  for  a 
b  r  e  a  <  ; 


> 

if  (requests)]  !=  '  E  '  Li  request:]]  !=  '  e  '  ) 

{ 

c  r  i  r,  t  f  (  "  I  H  T  =  R  C  G  M  M  A  N  D  =  =  >  "  )  *, 
s  c  ?  n  f  (  "  ■;  s  ".request); 
pr;.nr("\rAn"); 

if (request C0]=='I'  |  |  r eq j e s t Z  )  ]  =  =  'i *  || 
request '0]  =  ='C'  |  | r  e  q  j  e  s  t  C  0  J  =  =  '  d  *  || 
requestLi)]  =  ='4'  ||request'0]  =  ='a'  I) 
requestCO]=='^'  | |requestC0]=='r*) 

{ 

printf ( "Enter  unit  code  :  \n\n"); 

qet_unit_co'J.-()  ; 

state  =  check  unit_codaC)J 

> 

> 


while  (quit  !  =  true); 

ariatf  ("  G  G  0  0  3  4  Y  C  G  K  5  AGAIN  \  n  "  )  ; 

■  x  1 1 


I  !  1.1 


)  .  r_  : 
VERGE-  •  : 
MODULE 

’  idlle  n  a 
-  J'lC  r :  c\ 
AL GORITlM 
I  »J  P  L'  T  S 
GUT3  .  " 

J  L  u  (i  •'  k.  *  -i 


m  n  u  e  £  / 


7  MAY  i960 

1  .  0 

3  E  .R  :  1  .  \ 

E  5  rn  n  u  ? 

J  Display  s’"  '  i  J 

J  Display  coni.i  ,i 

J  none 

■  "'".at  coTtnand  s 

- •  iic  REA  j  :  none 


c  .  ■_  n  e  r  y 

j',i«?ry 


e  1  p  \  n  "  ) 
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GLOBAL  VAPIA3LE  CHANGED  :  none 
=  I L 5  5  READ  :  none 


=ILES  WRITTEN  : 
HARDWARE  INPUT 

hardware  output 
C ALL  ED  MODULES 
CALLING  modules 
A'JThER 
HISTORY 


non? 
none 
none 
:  main 
:  none 

:  LT  COL  GA3ER  A.  ELSHA.RAWY 
:  Version  1.0  by  Lt  Col  G  a  b  e  r  A. 
AFIT/EN  GCS  S  6  J  7  MAY  1986 


Elsharawy 


o  n  u  e  (  ) 

{ 

orintfC" \n\n\n")  J 

orintfC" 

orintfC" 

orintfC"  C  3  M M A  N  0  SUMMERY 


orintfC"  - 

orintfC"  I 

orintfC"  D 

orintfC"  A 

orintfC"  R 

onntfC"  H 

orintfC"  E 

■3turn! 

> 


AMMENDING  UNITS  DATA  \n"); 

_  \  n  \  n  "  )  : 

:  \n"j; 

-  \n\n")  : 

Insert  new  jnit.  \n"){ 

Delate  an  existing  unit.  \n"); 

Am mend  an  existing  unit  data.  \n" 
Retrieve  an  existing  unit  data.  \ 
HaloCdisplay  command  summery).  \n 
Exit  to  UNIX.  \n\n" ) J 


/  -I-  ||  1.3  c  n  a  c  k  _  u  n  i  t  _  c  o  d  e  *  / 

- - - 


DATE  :  7  MAY 

v  =  r s : o  n  :  l.o 

MODULE  NUMBER  : 

MODULE  NAME  : 

=jNCTI3N  : 

ALGORITHM  : 


:  m  3  -  r  s  : 

DJTf-^TS 

global  v a r : a ? l e 
Global  v  a  a  :  a  -a  l  r 
-  i  L E  S  READ 
=  1 1  E  S  WRIT'..  : 
"AR3WARE  INPUT 
•-•'.WARE  CUT  J  JT 

called  .modules 
CABLING  modules 

AuTmER 

HISTORY 


1956 

1.3 

check_unit_code 
Cnec’<  t  n  e  unit  code 

1  -  if  the  unit  code  exist  in  relation  UNIT 

returnCl) 

2  -  if  not  returnCO) 
none 

0  or  1 

READ  :  xdep,  x  1  ?  v  e  1  *  xtypei  x  n  u  m 

C  H  A  N  G  E  D  :  r  r  j  n  .■ 
none 
none 
none 
none 

:  main*  insert*  and  noclify_coTnand. 

:  none 

:  LT  COL  G  A  5  E  R  A.  ELSHARA„Y 

:  V.-rsion  1.0  by  Lt  Col  Gab  -  -  A.  Elsharawy 
AFIT/EN  GCS  R  6  J  7  MAY  InJ 


check.umt.codeC) 
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/ *  extern  char  xdepCOtxlevelCOtxtypeCOtxnumCO*/ 
*3  char  tdeoCSO*  tleval233*  ttypeC33»  t  n  u  m  C  4  3  ; 


*  * 

ran  ;e  of  u  is  unit 

*  3 

ratnaveCtdeo  =  u.dep, 

1 1  e  v  a  1  = 

*  R 

tnum  =  u.num) 

3  3 

uihere  u.dep 

=  x  d  e  p 

3  3 

and  u. level 

=  x 1 e  ve  1 

33 

and  u.type 

=  x  ty p  e 

*  3 

and  u.num 

=  xnum 

if  CstrcmpCxdep*  tdep)  = 

=  0 

level.  ttyoe  =  u.tyoe 


LL  strcmpCxlevel.  1 1  e  v  e  1 )  ==  0 
L  i.  strcmp(xtyoe»  1 1  y  p  e  )  ==  0 
EL  stfcmpCxnu.n,  tnun)  ==  0) 

< 

r  ;turn(l)! 

> 

else 

{ 

return(O) 

> 


A"-'  II  1 
/■■  - 
DATE 
VERSION 
-’JOULE:  : 
MODULE  : 
=  UNCTI  O' 

A  L  G  0  P  I  T  1 


2  ,  e  t  _  u  n  1 1  _  c  o  cl  e  / 

:  7  MAY  1936 


:  7  M  A  Y 

:  1.0 

\  U  M  E  :  3  : 

;;  a  i‘  z  : 


I  u  3  UTS 
0  J  r  P  J  T  5 

Global 

G  L  -  A  L 

■  I  l  :  j  A 
-  I  L  ~  S  rt 
9  A  -I  0  w  A  R 
H  A  7  0  *  A  P 
C  ALL  5  0 
CALLING 
A  j  7  M  E  R 
hi  STOP Y 


VAP I A3LE 
V  A  p  I  A  3  L  E 
E  AO 

BITTEN 
E  INPUT 
E  OUTPUT 

MODULES 

M  0  _■  ,  ~  _  u 


1.2 

get_unit_code 

1  -  a  c  c  e  c  *  unit  code  from  the  terminal 

2  -  check  its  syntax 

1  -  Display  message  to  request  u  -•  L  t  co 

(dec,  level »type»num), 

2  -  Acceot  the  unes  input 

3  -  OnecK  unit  code  s / n t a x 
<♦  -  If  correct  exit 

5  -  If  not  request  the  user  to  reinput 
the  unit  code  or  quit. 
xdeo»xlevel»*t/::s»xnu.m 
messes  s s 
p  =  i  r  : 

CmANGED  :  x  d a  p  t  xlevelj  xtype»  xnum. 

:  none 
:  none 
:  none 
:  none 

:  main*  insert  i  mocfify_comm?nd. 

:  none 

:  LT  COL  GA3ER  A.  ELSHARAwY 
:  Version  1.0  by  Lt  Col  Saber  A.  Elsho 
AFIT/EN  GCS  ?SJ  7  MAY  1936 


.  oit_coaaO 


/  *  >  a  t  „•  •'  n  char  xdepC0*xlevelC0, 


> J  i  *  i  u  m  C  0  £/ 
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rsjntsr  =  15 
30 
{ 

DrintfC "department  =>  ")I 
scant  ("5Ss"i)(  jep)  i 
orinif ("\n")  ; 
if  (xdepCDO  ==  'q '  |  I 
ex i t C  1 )  : 

orir,  tfC"  level  =  =  =  =  =  =  > 
scanf("?s"*xl9vel)  ; 
onntt("\n")  ; 

Dnntf  ("typs  =  =  =  =  =  =  => 
sc3nfC"»5"*xtype); 
onntf("\n")  ; 
printfC" number  =====>  " ) 
scant  C"'is"*xnun)  ; 
printf ("Nn")  ; 
if 


xdeoCOO  = - 


((strlen(xdep)  ! 

=  2)  I  |  C 

strlen(xle 

vel)  1 

=  2) 

1  1 

(strlen(xtype) 

! =  2)  || 

(strlen(xn 

um)  !  = 

3)) 

reenter  =  0  * 
o  r  x  n  t  f ( " T  n  e  key 

formate 

shoulci  be 

c  2  ,  c  2 

,  c  3 

\n"  ) ; 

printfC  "To  exit 

print  w 

kn"); 

> 

else 

< 

re?nt  ?r  =  1  J 

> 


i-'ile  ('•-•enter  !=  1); 

ratjm; 


} 


•  II  1  .  -*  insert  / 
/** - 


DATE  :  7  MAY 

VERSION  :  1.0 

MODULE  N J  M 5  E  3  : 
MODULE  NAME  : 

W  *  w  '  -  •  «  • 

;  l  j :  - :  '  i  ’  : 


I  n  3  j  r  o 

3  U  T  3  J  " 
j  L  2 


1986 
1 . 4 

insert 

Insert  new  unit  into  Z M  A  D 3 

1  -  check  t  n  e  un.t  code  (xdeo»xl?vel»xty3.,xnun) 

2  -  if  tne  unit  code  is  not  exist  in  UNIT  MI  DEL  relation 

by  calling  cneck_unit_model  aske  the  user  if  he 
or  sne  mants  to  insrt  a  new  unit  model. 

3  -  according  to  the  user  request  call  in s er t_u n i t _m o d a  1 

or  return. 

4  -  acceot  unit  oata  from  the  terminal  Coercentage* 

location,  instruction  numoer) 

5  -  check  to?  unit  data,  anci  if  .any  not  in  its  domain 

aske  the  use’*  to  reenter  it. 

6  -  call  in-,  -*rt_oian 

7  -  am  me-’-:  c  ■  •  let  ions  UNIT,  COMMAND 
3  -  retJ'n. 

uut  da  t  a 
-  ■  s  s  e  g  ?  • 

?  E  A  D  :  xdec,  x  1  e  v  e  l  •  x  ,  x  n  „  . 


150 
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y  d  e  p  *  yleval*  y  t  y  p  a  »  u  n  u  m  . 


GLOBAL  VARIA3LE  CHANGED 
PILES  READ  :  none 

FILES  WRITTEN  :  non  a 

HARO*ARE  INPUT  :  nona 
HARDWARE  OUTPUT:  nona 
CALLED  MODULES  :  main 
CALLING  MODULES  :  check 
AUTHER  :  LT  CO 

HISTORY  :  7  a  r  s  l 


check_unit_modal »  i n sen t_un i t_mod a  1 ,  insart_oian 
LT  COL  G  A  3  E  R  A.  ELSnARAWY 

Van  sion  1.0  » y  Lt  Col  G  a  b  e  r  A.  Elsharao/y 
A  c  I  T  /  E  N  GCS  3 6 J  7  MAY  1986 


.nsertO 

{ 

int  raantar*  up  a  r  c  e  n  t  a  g  e  ; 

*  *  cnar  uloca  tionC23»  uinstructionC60*resC215 
if  (  cne  c  k_un  i  t_mocla  1  (  )  ==  falsa) 

{ 

printfC" Do  you  u  a  n  t  to  insert  a  ne^  unit  modal  (y/n) 
scanfC"?s",ras)  ; 

D^intf ("\n"  ); 
ifCrasCuO  !=  'y') 

r  a  t  u  r  n  5 
a  1  S  > 

insert_unit_noclal()  ; 

> 

ormtfC"  Enter  j^t  oata  :  \n\->"); 


pr;n‘  Parc  a-tage  :  ")5 
s  c  a  n  f  I  "  3  ci "  ,  i  u  o  a  r  c  e  n  t  a e  )  J 
orxntfC"\n"); 
if  Cuparcentaoa  >  100) 

printfC "oancentage  must  be  <=  1  0 0 \ n " ) J 


iu h i  1  e  (uparcantaqa  >  100)5 
cl  o 
{ 

■  ."'.tf  ("Location  5  » )  5 
f  (  "  *  s  "  ,  ulocation); 

-  *  i  c  f C  "\n”)5 

i  1  C ( j  t  c  1  j  n ( u  location)  ==  1) 


ulocationCCI  =  =  'a'  II  ulocationCO)  ==  '  b ' 
ulo*ationCjj  - -  'c'  ||  uloc?ti vr 
uL  ...  :  i  o  n  COO  ==  'a'  II  u  1  o  c  a  t  i  o  • 
raantar  =  falsa? 
a  1  s  a 
{ 

printfC"  Unracojnnad  location  \n")5 
reent'r  =  trua! 

> 


II  ulocatio- 
II  ulocatio 


ju  n  i  i  ..  C  r  a  i  n  t  _■ 

r  ~  l  n  t  f  C  "  I  n  s  C  r 


'  =  =  t  r  u  a  )  5 

:  t  i  o n  n'jT1) 


:  " )  5 
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pnntf  ("  \n"); 

*  »  sop  »ncl  to  unit  (  d  e  p  =  x  d  e  p  i  level  =  x  1  e  v  e  1  *  type  =  x  t  y  p  e  » 

*  %  nua  =  x  n  u  m  ,  percentage  =  upercentage* 

*«  location  =  ulocation*  instruction  =  jinstruct 

/*  T  n  e  unit  relation  is  updated  noui  * / 
msert_pian(); 

/ ts  The  plan  relation  is  updated  non)  $/ 

/ ~  Save  unit  code  to  use  get_unit_code  module  to  enter 
t  n  e  command  unit  cod?  * / 
strcpyCyd e  p  ,  x  d  e  p  )  ; 
strcpyC/levelfxlevel); 
strcpyCytype,xtypa)  ! 
strop, (ynum,xnum); 
c.  o 
( 

prmtfC"  Inter  command  unit  data  :  \n\n" ); 

get_jnit_codeC)» 

if(cnack_unit_codeC)  ==  false) 

{ 

D'-;nt*("Tnis  unit  is  not  exist\n"); 
reenter  =  true; 

) 

else 

reenter  =  false; 

> 

a r 1 1  a  (rjjntar  ==  true); 

*  •*  aooerd  to  command  (cdep  =  xdep,  cleval  =  xlsvel»  ctype  =  xtype, 

«»  cnu-=»-'jm,  dep=ydap*  levol  =  yleveii  tyoe-ytyoa*  num  =  ynum) 

r  e  t  J  r  o  ; 

> 


/”  II  1.4.1  Che 

DATE  :  7  v  A  Y 

VERSIDU  :  1.0 
MODULE  NUM3  S R  : 
MODULE  NAME  : 
“unction 


i  _  j  0  I  T  rt  M 


:  s 3  u  r  s  : 

j  u  t  ?  j  I  s  : 

. 0  2  A  L  VARIABLE 

)  .  :  =  al  variable 
-=s  read  : 

written  : 
-  a  5 ;  «  a  r  :  :  n  3  u  t 

J A \z „ A ’ 0  OUTPUT 
: all  ED  MODULES 
;al’  :  modules 


m  .  , r :  a  r 


'..unit_model  / 


19  3  6 

1 . 4 

check_unit_model 

cnec<  if  toe  unit  model  cede  (x.iep»xlevel»xtype) 
is  exist  in  tne  data  base. 

1  -  if  the  unit  model  code  exist  in  the  relation 

UNITMODEL  returnCl) 

Z  -  if  not  return(O) 
none 
1  o  r  0 

READ  :  xclepi  xl  evil  ,  xtype. 

C  "  A \  t  E  j  :  none 

no-, 
none 
n or  e 
none 

:  insert 

:  n  •  • 

•  If  COL  u  i  0  E  R  A .  ELSHARirtY 

•  Version  1 .  :>  /  L  *  r  n  l  G  a  >  ■  •  E  l  -  h  a  r  a  jj  y 

A  F  I  T  /  E  M  G  L  ■  '  !  "  MAY  1  • 
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:n;:k_un:t_irodil() 

{ 

k  *  extern  char  xdepC3»xlavelC3»xtycaC3£/ 

*  *  char  « cl  *  p  C  3  3  *  mlevelC33*  <ntyoeC30C 

*  «  range  of  u  is  unitmodel 


ratrieveCmdeo  = 

u.dept  ml 

e  w  e  1  = 

:*  * 

jjnere 

u  .  cl  e  p  = 

x  cl  e  p 

4  ft 

and 

u.leval  - 

x  1  a  v  e 

4  4 

and 

u . type  = 

x  ty  p  e 

if  C  s  t  r  c  h  p ( xdao. 

m  cl  e  d  )  =  = 

0 

=  u.typa) 


LL  strcmpCxlevel*  mlevel)  ==  0 
Li  itrc.»j(xtyp3i  ntyoe)  ==  0) 

{ 

r  e  tur n( 1 ) ; 

> 

else 

{ 

return(G); 

> 


/  *  II  1  .  ■* .  2  inser*  i,nit_nodel  ::  / 


v.  T  i  j'i 

:  p :  t  -  • 


“<  p  U  T  3 
JTPJT3 
-  3  -  A  L 

~  '  i 

i  l  " 

I  •_  :  j  W 
4  .P J  WAP 
4  ■<.  o  n  A  p 

in 

.1  ‘  1  r 
I  -  zR 
.  ",  T  0  P  Y 


:  insert  a  new  cnit  hoae  1  into  DM  A  3  3 
:  1  -  accept  unit  nr.’--? 

i  ~  a  c  coot  uni4:  o  '  ‘  n  c  »  a-'  I  cneck  it 

3  -  append  to  r  t-.  1 1  o  n  u  \  I  T  M  ;  D  E  l 

x d e  j  i  xl  ev  ji  ix  t/se»l)al?n;  3 ,  '  -i3 

4  -  call  insert_person 

5  -  call  insert_arn 

5  -  return. 

:  user  inputC  nanj,  balance) 


V  A  P  I  4  3  L  3  ?  E  A  0  :  xclept  xlevel.  x  t  y  p  e  *  xnuin 

V  A  P  I  4  3  L  E  CHANGED  :  none 

.41  :  none 

PITTED  :  none 
E  INPUT  :  none 
=  OUTPUT:  none 

MODULE  S  :  insert 

MODULES  :  insert.person,  inser*_arm 
:  LT  COL  G  A  B  E  R  A.  ELSmAPAwY 
:  Version  1.0  i ,  Lt  Col  G  a  b  e  r  A 

ArlT/i'l  GCS  3  S  J  7  MAY  19  3  6 


lsha^auj/ 


n  s  e  r  t  _  u  n  *  t_model(  ) 
'_sar  x  x  n  a  ’  r  '  .  • 
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int  reantar; 

orintfC" enter  unit  model  data 
printfC"  2 

printfC" \n"); 
printfC "name  : 
fg»tsCxxname»31* stdin); 
fgetsCxxname,31»stdin)  : 
printfC "\n")  ; 
xxnameC313  =  '  \  0  ' ! 
d  o 
C 

orintfC" balance  :  "); 
scanfC" &  s  " »  x  Pa  1  )  J 
orintfC "\n")  J 


\n")  ; 


if  (xbslCOD  =: 


1  '  ||  x  b  a  1  C  0  3  ==  '2  '  |  | 


xbalCOD  ==  '3'  | I  xbalCOl  == 


x balC 03  ==  '5' 


xbalCOD  = - 


•^'11 

•6*) 


reantar  =  0; 

»  a  p  o  s n  d  to  unitmodelCdep^xdept  level=xlevelt  ty 
4  nane=xxname*  balan:a  =  xbal) 

> 

else 

C 

reenter  =  1 ; 

orintfC "Sal? nee  should  he  in  the  range  1  :  6 \ n " ) 

> 

) 

v  h  i  1  ?  Creer.ter  ==  1): 
insert_personC): 
insert^armC); 
r  -  turn! 


||  1.4.  2.2  insert.arm 


3  A  r  z  :  7  z  A  Y 

7  £  R S 1 3  N  :  1.0 
■\  '  J  L  =  N  ’j  M  3  S  R  : 
■*.  JuLE  N  A  M  E  : 

.  i  *,  t  i  o  m  : 

x  l  3  •: 5 :  t  h  m  : 


I 0  U  T  j 
0  'J  T  o  U  T  3 

j  L 36AL  V  A  R I  A  3  L 
/.OPAL  VAKIA3L 
=  I  L  c  3  ;  '  O 

=  IL-  . 

dAR.AARE  I  ••  ■'  J  : 


1986 


1.0 

insert_arm 

insert  new  unit  model  arm, -n  ament  data  into  3  M  A  Q  6 

1  -  accept  arm  departmentCxadep) 

2  -  accept  arm  name  C  x  n  a  m  :•  ) 

3  -  call  checK_arm 

4  -  if  check_arm  =  true  append  armm ament  data 

to  tn?  relation  4SSIGNA 

5  -  if  not  display  an  error  nes  , 

6  -  aske  the  user  to  enter  a  n o  t  n  e  r  arm  data 

7  -  return  uhen  the  user  type  " * " . 
u  ••  }  r  inputCxadjp.xnam?) 


£  AD 

•  A  U  3  E  0 


<  l  e  v  e  1  #  xtype* 


t  *  n  a  me 


P  ,  «  n  n  - 
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HARDWA  RE  OUTPUT 
CALLED  MOD  JL  E  A 
CALLING  MODULES 
A  'J  T  H  E  R 
HI  STORY 


none 

insart.umt.^odcl 

chack.am 

LT  COL  GABER  A.  ELSrtARAWY 

Version  1.0  Gy  Lt  Col  G  a  6  e  r  A.  Els^araiy 
AFIT/EN  GCS  36J  7  MAY  1936 


■*/ 


insert_ar*mC) 

{ 

int  reenter; 

printfC"  Insert  armir  ament  data  :  \n."); 
print^C"  (at  end  print  '  *  '  )  \  n  \  n  "  )  ; 
a  o 
< 


o  " ); 


*# 

*  ? 


printfC"Arm  department 
s  c  a  n  f  C  "  t  s  "  ,  x  a  d  >  p  )  I 
printfC” \n" ) ; 
lfCxadepCOD  ==  '*') 
reenter  =  false; 
else 
< 

crintfC"  C 

printfC "\n">; 
p  r i n  t  f ( " A r  r  name  ;  "  )  ; 

f  g  e  t  s  (  x  n  a  v  e  *  3  1  *  s  t  ci  i  n  )  ; 
fgetsCxnare, 31 i stdin); 
pr;ntt("\nM) ; 
xn a met  3 13  -  ' \ 9 ' ; 

orintf  ("  u'vier  of  arms 
s  c  a  r  f  (  "  >  :  »  E  x  o  o  ■  a  )  J 

orintf("'\  ■"  )  ; 
l  f 

CcHecK_armC)  ==  trj?) 

{ 

append  to  assignaCdep-=xdep»  level=xlevel»  tyoe  =  xtyp 
adeo  =  xadeo,  n  a  m  3  =  x  n  a  .ti  e  ,  num  =  xnu'na) 
reenter  =  true; 

> 


M) ; 


else 


{ 


orintf ("unnecnad 
reenter  =  true; 


tns.nt  /  arm  n  a  m  e  \  n  "  )  ; 


> 


> 


J  ~  i  1  ?  (reenter  ==  true); 
re  turn! 


'..‘♦.2.1  c  n  ■> c k  arm  *  / 


/ 


'336 


Vision  :  1 . 
MODULE  N  J  3  E  R 


MOD  'j  1 


2  .  1 

n 


♦  V. . 


1 
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V-- 


=uNCTI0N 

ALGORITHM 


inputs  : 

outputs  : 

3L0SAL  VARIABLE 
3L3BAL  VARIA3LE 
p  I  L  E  S  READ  : 
=  ILES  WRITTEN  : 
HARDWARE  input 
HARDWARE  OUTPUT 
O  A  L  l  E  0  MODULES 
SAILING  MODULES 
Aw 

-i  I  STORY 


chsck  the  correctness  the  input  arm  name  and  department 

1  -  if  the  xadep  and  x n a m e  are  exist  in  tne  relation 

4 R MM  AMENT  raturn(i) 

2  -  if  not  return(O). 
none 

1  or  0 

READ  :  xaclep,  xname. 

CHANGED  :  none 
none 
none 
none 
none 

:  insert, arm 
:  none 

.*  LT  CCL  GA5ER  A.  ELS-ARAWY 

:  Version  1.0  by  Lt  Col  Gaber  A.  Elsharsiy 
APIT/En  GCS  8  6  J  7  M-.Y  1935 


checR_arm(;  ) 

{ 

**  char  t  a  c!  e  o  C  3  0  »  tnameCcIOj 


4  * 

r  a .  r  g  e  of  a  is  armmaneot 

5  4 

retrieveltadep  = 

a  .  a  d  e  o 

•  t  n  a  n*  e 

w  n  v - t  a.adep 

=  x  a  ci  a  p 

t  ? 

arc,  a  .  n  a  r,  e 

=  x  n  a  r  a 

l  ■*  1  strcmpCtac,  ep  , 

N  JLL  ) 

•.1 

O 

II 

st-cmoCtname* 

NULL) 

!  =  0) 

r  s  *.  j  r  n  (  1  )  ! 
<?  i  5  c 

returnCO)  ; 


/ 


/*  II  1 . A .  2.  1 

/  * - 

GATE  t  7  ’ 

VERSION  :  1  .  j 

MOD E  N  u  3  E  R 


insert_person 


Y  1986 

:  l .4. 2.  l 


/ 


"  "OLE  NAME 
=  u  *.  o  t  i :  \ 

A  L  GCRIT.im 


INPUTS  : 

:  j  r  =>  u  t  s  : 

0  s  A  L  VARIABLE 
. _ ' • A L  VARIABLE 
=  I L  t 3  READ 


insert.person 

’  n  s  e  r  t  tne  nan  unit  model  personnel  data  into  D  M  A  D  5 

-  accept  xodep  from  terminal 

2  -  acceot  xspec  from  terminal 

3  -  call  c h e c k _p ?r so n 

»♦  -  if  check_person  =  true  append  xpdep  and  xsoec 
to  the  relation  ASSIGN? 

3  -  if  not  display  an  error  message 

-  asKe  the  user  to  enter  anotn-r  personnel  data 
/  -  if  the  user  enter  "  d  "  return. 

user  inputCxpdeo,  uspe.) 
messages 

REAO  :  x  cl  ?  c  *  x  1  e  v  e  1 1  xtype,  xn-mt»pdep»xsoeC. 

C  h  A  n  3  E  j  :  a  ,  xspec. 

n  s 


P  I  L  E  S  W  *  1  T  E  N  :  r  . .  •  • 

H  A  R  0  m  1  1  N  J  T  :  n  j  n  » 


output:  none 
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CALLED  MODULES 
CALLING  MODULES 
aut^er 
HISTORY 


insert_unit_;nodel 
Check_person 
LT  COL  GASES  A.  E 
Version  1.0  i:y  L  t 
APIT/EN  GCS  3  6  J 


ELSHARAwY 
t  Col  Galaer  . 
7  MAY  1936 


Elsharawy 


insert.DsrsonC) 

{ 

int  r  eenter ; 

arint^ (" Insert  personnel  data  :  \  n  "  )  I 
d  f  i  n  t  f  (  11  Cat  and  print  '  d '  )  \  n  \  n  "  )  • 
d  o 
{ 

p  r  i  n  t  *  ( "Parson  department  I  "  )  ; 
scanfCis"  »xcd9p0; 

Drintf ("\n")  ! 
lfCxpdePCOO  ==  '*') 

-eenter  =  falsa! 
else 
< 

Drmtf  Carson  speciality  :  "); 

scanf(  11  ",  5  11 1  x  s  p  e  c  )  ! 
srintf ("\n") ; 

or  intfC" Nun  Par  of  personnel  !  "  )  ; 

$Ctirf("id"iixr.jTo)  l 

printfC"\n" ) ; 

if  (cnacx.oarsor'O  =  =  true) 

{ 


else 


1  o  p  e  n  cl  to  ?S3ignp(d9C  =  xdao,  leval=xlevel»  ty 
pc'eo=xpdep»  5Dec=xspec»  nu'i  =  xnurnp) 
reenter  =  t'jJ! 


crintf  ("Uma:had  deoartmant  /  s  p  a  c  l  a  1 1 1  y \n  "  )  J 
reenter  =  true! 


> 

> 

o  -  i  1 
re 


.•"ter  =  =  true); 


II  1.4. 2. 1.1  check  person  *  / 


DATE  :  7  M  A  Y 

1  9  36 

V  E  9  L  ~  ,  :  1.0 

M  ■  U  L  E  N  U  M  3  c  R  I 

1 .4. 2  .  1  .  1 

•r  ,  j  l  £  name  : 

cdec<_De'",m 

=  ■ .  0  T 1 3  N  : 

check  the  don a  in 

of  the  ant' 

■  ee.'jonnel  data. 

ALjORIThM  • 

1  -  if  xodep  and 

x  n  a  in  a  are  ?■ 

i*t  in  the  relation 

3  E  9  3  0  N  retur 

n(  1  ) 

2  -  if  not  retur 

) 

I  <SUT5  : 

■>  n  e 

OUTPUTS  : 

1  or  0 

May  2  2  10:50  1986  o  m  a  e  d  .  q  Pag?  14 


GLOBAL  VARIABLE  READ 
GLOBAL  VARIABLE  CHANGED 
FILES  R£AG  :  non? 
FILES  WRITTEN  :  none 
nAROWARE  INPUT  :  none 
HARDWARE  output:  none 
CALLEO  MODULES  :  inssr 
CALLING  MODULES  :  none 


xpdep  » 


AUTHER 

HISTORY 


insart.pjsson 

none 

LT  COL  GASSR  A.  ELSHARAWY 
Version  1.0  by  Lt  Col  Gainer 
AFIT/EN  GCS  86J  7  MAY  193' 


Elsharauiy 


cnacK 

{ 


DSrsonO 


*  *  cbar  tpdeoC30»  tspecC43; 

*  *  range  of  p  is  person 

*  *  retr.eveCtpdep  =  p  .  a  d  e  p  »  ts pec 

»#  j/  h  ere  p.pdep  =  xpdep 

-*  ?  a  n  ci  p.SDec  =  xspsc 

lfCstnc'T’pCxp  dep»  tpdep)  ==  0  L : 
sfctppCxspec,  t  s  o  n  c  )  ==  0) 
raturn(l); 
else 

r-turnCO); 


/  *  II  1.4.3  insert_plan  *  / 


=  p . sp  ec  ) 


J  M  7  E  :  I  ••‘AY 

VERSION  :  1.0 

MODULE  NUMBER  : 
-1 0  D  U  L  =  NAME  I 
^UNCTION  : 

ALGORITHM  : 


.  'j  r  j  7  j  i 

3  L  0  5  A  L  VARIABLE 
j  j  -  A  V  A  R  .  A  3  U  z 
=  I  L  E  s  read  : 
-  I  L  :  S  WRITTEN  : 
HARDWARE  I  ,  ?  J  T 
H  A  R  :  ^  A  OUTPUT 
'AILED  MODULES 
CALL  In  3  «■'  '  ,LES 
A  U  T  H  E  R 
HIST  '  -  ' 


l  1  3  z 


1.4.3 

inser  t_p lan 

add  plan(s)  to  a  na.  unit. 

1  -  accept  plan  nameCxplan) 

2  -  call  cneck_planid 

3  -  if  ciack.nl  an  =  t  r  j  : ,  append  a  n  ?  u /  tuple  to 

tne  relation  PLAN 

“♦  -  if  not  display  ,v.  error  message 
5  -  aske  tne  user  to  a :!  c;  anotnar  plan 
-  retern  jj  n  e  n  tne  us’r  t ,  r  >  "  v  " . 

user  input  (xplan) 
naj  tuple  to  the  relation  PLAN 
READ  :  xdepi  x  lev  el*  xtypa*  xnun,  xplan. 

Changed  :  xplan 


insert 
CHack.nl  an 

L  T  COL  G  A  B  E  R  A  .  E  L  3  •  t  \  A  y 

Version  1.0  o  y  Lt  Col  G  a  .  j  e  r  A.  ElsHaraaiy 
Arif/..  GCS  S6J  7  MAY  1936 


-  - */ 


VLV.vN 


i*  c>  o 
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m  ser  t_pl an (  ) 

{ 

i  n  t  reenter! 

orint#(" Enter  p 1  a  n ( s  )  •  at  end  print  '  *  '  \  n  \  n  "  )  J 
d  o 

{ 

printfC" Defense  plan  :  "); 

5car#( " %s"»  x  p 1  an  )  J 
orintf ("\n")5 
if  CxplanCDD  ==  '*') 
reenter  =  false; 

else 

if(chack_olanid()  ==  false) 

{ 

ormtfC"  Unrecognized  plan  \  n  "  )  ; 
reenter  =  true! 

> 

else 

{ 

n  append  to  Plan  (dep=xdao»  level=xlevel* 

3  *  nun  =  x nun*  plan 'xplan) 

reenter  =  t  r  u  •  i 

) 

> 

jjnila  Craente*-  =  =  true); 
r  e  t  u  r  r. ; 

> 


/  *  II  1  .  4  .  3  .  1  c  h  ?  p  k  _  p  1  a  n  i  c!  *  / 
/  - 


3 1 : i  :  7  '•'.ay 

(  :  u  .  j  'i  ;  1*0 

MODULE  NUMBER  : 

MODULE  A  m  f  : 

s UNCTION  : 

ALGORITHM  ; 


:  u  r  -"j  r  s  ; 

"•  L  0  5  A  L  V  A  I  4  3  L  E 
G  L  3  3  A  L  V  A  A  I  A  3  L  = 
"IlpS  <  c  A  _/  ; 

= : L ' -  WRITTEN  : 

■*  ■*  \  •  -  i  input 
m  a  ? :  „  a  a  :  D  u  t  3  u  t 

A  L  L  E  ^  "  DULES 

ALLIED  ■  ■  L  E  3 
U  T  r  E  : 

4 :  s  ■ :  > 


1  9  S  3 

1 . 4  .  3  .  1 
check_olanicl 

check  the  domain  of  tna  entered 

1  -  if  xolan  is  exist  in  the  rei 

returnCl) 

2  -  i  *  not  r  e  t  o  *  C  j  ) . 
none 

0  o  r  1 

READ  ;  *r ien 

Changed  ;  none 
none 
none 
none 
none 

:  isert_plan 
:  none 

;  lt  col  gaser  a.  slsh.ara«y 

:  Version  1.0  ; ,  Lt  Gol  G  a  b  e  r  A. 

A  =  I  T  /  E  N  “  0  j  l-J  7  MAY  1956 


tyoe=xtype» 


o  1  a  n  . 

ation  PLANID 


E  1  =  h  a  n  -  / 


"*N 

4  *&>' 
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char  tidC  2  ]  ! 
rang;  of  pi  is  p  1  a  n  l  d 
retnaveCtid  =  pi. id) 
where  pi. id  =  xplan 
if(strcnp(xpl?n,tid)  =  = 
return(trua) 5 
else 

return(false) ; 


II  1.6  delete 


jAT; 

y  e  r  s  i  c  > 

M  3  D  J  L  E 
MODULE 
=  u  nc  t  i ; 
al  00=? 


7  MAY  1935 
1  .  0 


N  J  M  3  E  R 
NAME 


lelete  u  n  i  t  (  s  )  from  3  MADE 

-  display  "are  you  sure"  to  give  the  user  a  chance 
to  quit 

-  Lr  toe  resoooc;  is  n  *  exit. 


Lr  toe  resoooc;  is  n  *  exit, 
call  ctree 

-  if  ctree  >  1  (the  unit  nas  subuits) 
a  s  «  a  the  u s  e  r  <  d  o  you  want  to  delete 
all  subunits) 

if  the  responce  is  n  exit, 
delete  all  unit  exist  in  the  relation 
CGRM-TIJ\  from  the  r-latior.s  UNIT* 

=  l  A  N ,  and  3  3  M  ‘  .  D . 
return. 


INPUTS 
3  'J  T  P  U  T 
IDEAL 

j  L  0  5  A  L 
=  ILES  : 


:  user  input(y/n) 
:  ms  ss  a  ;  ;  s 

VARIA3LE  9  c  A  0  :  xdeo* 


xcleo*  xlevel*  xtyoe*  x  n  u  m  , 
ydap*  yleuel*  y  t  yv  i  ynum. 


Hi R  3 i a 
IDLED 
3  -  . I  N 


VARIABLE 
R  E  AG  : 
«  R  I  T  T  o  N  J 
R  E  INPUT 
RE  OUTPUT 
M  C  0  J  L  E  3 


CHANGED 


main 
ctree 
LT  COL 


,  A  3  E  R 


cuoHA.RAftY 


Version  1 
A  -  I T/ EN  G 


.  0  b y  L  t  Col  Caber  A  .  E  1  s  h a r  a 
CS  8  6  J  7  MAY  19  3  6 


c  o - r  surei^j, 
it  n  1  u  I 

'('Ur;  v 

•  -  ‘  * '  u  ■  *  1  9  ■“»  U 

-T.'rO'Nn"); 
if  (sureCOl  ! 
rstjr- • 


-.*•  ...Jk.  -,.mt I,,  —ft. 


sura 
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valu  =  c  t ree(  )  J 
if  (valu  >  1) 

{ 

printf(M0o  you  want  to  delate  all  subunits  (y/n)  "); 
s  c  a  n  f  (  "  i  s  "  •  s  u  r  a  )  ; 
printf (" \n" ); 
if  CsureCOD  !=  '  y  ' ) 

( 

return  ; 

> 

> 


*  « 

range  of 

f  is  formation 

*  * 

range  of 

u  is  unit 

*  $ 

rsn,.-  of 

p  is  plan 

•r  * 

range  of 

c  is  command 

/  *  s  t  a  r  t 

delete*/ 

3  J* 

d  e  1  e  t  a  u 

where  (u.deo=  f.dap 

a  n  cl 

u.leval=f. level  and 

*  ft 

u.tyoa=f.typa 

and 

u.num=f.num) 

/  *  d  e  1  a  t 

a  cl  from  UNIT*/ 

*  * 

delete  o 

where  (p.dep  =  f.deo 

an  cl 

o . 1 e v e 1  =  f . 1 e v e  1  and 

i  * 

o.tyoe=f.tyoe 

and 

o.num  =  f.num) 

/  *  d  a  1  a  t 

a  cl  from  PLAN  *  / 

*  a 

delete  c 

unera  (c.dep  =  f.dep 

an  cl 

c.level=f. level  and 

*  5 

c.typa=f.typa 

and 

c.nui  =  f.num) 

/  •  deleted  fron  C  3  M M i N 0  v/ 

r  e  t  u  r  n  ; 


V 


V>  .V  V. 

'I*  *,*  ’I*  v» 


*/ 


/=••  II  l.o.l  - 

/  * - -  - 

J  A  T  5  :  t 

i  E  R  S  I  3  N  :  1  .  j 
MODULE  NUMBER 
MODULE  N  A  M  E 
F d NOTION 
AL'jCPITlH'i 


_•  *  V  / 


T  19  5  6 


1.6.1 


ctree 

collect  formation's  units  t n rough  a  root 

1  -  create  the  temporary  relation  °ARENT 

2  -  creata  the  ta moorary  relation  SONS 

3  -  delate  the  contents  of  t-1*  ralatmoo  FC  R M A  T  1 3  N 

4  -  ape.'*  --  to  °  A  R  r  NT  t  ~  e  corn;  •  9  unite  from  t  h  a 

global  variables  xdsoixlav  .■!  ixtypuixnun) 

5  -  append  to  SONS  the  units  commanded  directly 

by  any  unit  in  rN:\T(usin3  the  relation 
COMMAND) 


6  -  append  to  FORMATION  ail  units  in  PARENT. 

7  -  delete  the  contents  of  P  i  ?  =  N  T  . 

5  -  if  number  of  units  in  S0N5  <  1  exit 
alse  continue. 

9  -  a  p  p  e  n  ;l  to  par  - it  all  units  in  SONS 

10-  delate  +  contents  of  SONS 

11-  30  to  j  i;p  o 

12-  :l  ?  j  ; o  y  SONS 

13-  c!  >  3  t  r  o  y  BARENTS 

14-  if  nj"i1)*-  nf  tuples  in  -  ;  -  “M  T  I  3  \  -  1  ,  return(l). 

alse  rot  .  i  2  )  . 


:  r  o  *  unit 


141 


Jkj Jbfc.A 


■ v  *  ~  -  l  — 


•  V-.  -  " l"' -  •' . 
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OUTPUTS  :  th a  r e 1  a ' 

GLOBAL  VARIABLE  READ 
S  L  0  E  A  L  VARIABLE  CHANGED 
-ILES  READ  :  nona 
=ILES  WRITTEN  :  none 
HARDWARE  INPUT  :  none 
HARDWARE  OUTPUT:  none 
CALLED  MODULES  :  delete 
CALLING  MODULES  :  none 


the  relation  FORMATION 

READ  :  x  d  e  p  »  xlevel*  xtype»  xnuJi 

Changed  :  none 


A  OTHER 
Hi  STORY 


LT  COL  GASER  A.  ELSHARAWY 

Version  1.0  by  Lt  Col  G  a  b  e  r  A.  Elsharaiuy 
ArlT/EN  GCS  96J  7  MAY  1986 


e  e(  ) 


ssaxtarn  char  xdep»xlevel»xtype»xnum  £  / 
int  fiag»flif2*f3*#4; 

create  parentCciap=  c2»level=  c2»type=  c  2  *  n  u  m  =  c 


create 


sons(dep=  c2*level=  c2|type=  c  2  *  n  u  m  =  c 


•*  5 

range 

o  f 

p  is 

parent 

?  i 

-an,  n 

0  f 

5  IS 

sons 

:  ? 

range 

0  f 

f  is 

formation 

*  5 

range 

o  f 

c  is 

c  o  m  n  a  n  d 

•4  S 

dilate 

f 

t  5 

append 

t  0 

par 

entCdeo  =  x 

*  $ 

njr, 

*1  0 

{ 

r  D3  >n>i  tc  s  o  n  s  C  d  a  o  =  c.deptl^Vrl-  c.level»t  yp  ;  = 

n  u  m  =  c.nuT) 
am r  j  c  .  c  cl e  p  =  p  .  cl  e  o 

and  c.clevel  -  p .  level 
and  c.ctype  =  o.tyoe 
and  c.cnum  =  p.ncm 
append  to  for. -nation  (p.all) 


append  to  tor-nation  Qp.all 
delete  p 
retrieve  (flag  =  countCs. dep)> 
i^CflagbG) 

( 

append  to  parent  C  s  .  a 1 1 ) 
delete  3 


-lie  C  f I  • 

,  >  C) 

• 

• 

r  2  *  r  i  »  v  -  • 

re*  — 

count(f.doaD) 

retrieve 

■y  — 

count(f.l./el)9 

retrieve 

(  f  3  = 

covntCf .tyoi)) 

retrieve 

II 

t 

W 

cojntCf.no-n)) 

uoy  pa-.-  *. 
.Ira/  53,-ij 

‘  1  >  1  II  f  2 
raturn(2); 


I  f  3  > 


•  >  1) 
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/ *  ||  1.5  amnend  / 


date  :  7  M4 y 
VERSION  :  1.0 
MODULE  NUMBER  : 
MODULE  NAME  : 
=UNCTI0N  : 

algorithm  : 


I  N  3  U  T  5  : 

:  U  T  P  u  T  s 

GLOBAL  variable 
j  L  0  5  A  L  variable 
=iles  read 

“ILES  WRITTEN 

HARDWARE  input 

-tARGWARE  OUTPUT 
CALLED  MODULES 
GALLING  MODULES 

A  JT-:  A 

-*1  STORY 


1936 
1.  5 

a  m  m  s  n  cl 

am  men  cl  unit  data 

1  -  print  summery  of  the  modification  codes 

2  -  acco-fling  to  the  input  modification  code 

call  a  suitable  module 

3  -  aska  tne  user  to  enter  another  modification 

code 

A  -  return  when  tne  user  t  /  p  ' E  '  or  'a  ' 
modification  codo 
messages 
READ  :  none 
CnANSED  :  none 
:  none 
:  none 
none 
:  none 
:  main 

:  modify_commancl*  mcdify_plant  modify_oercent 
nodify.location,  moc'ify_inst. 

:  LT  CDL  GIBER  A.  E  L  3  -  A  R  A  * Y 

:  Varsion  1.0  by  Lt  Col  Gabsr  A.  Elsharawy 
A  r  I  T  /  5  N  GCS  E6J  7  f-'  A  Y  1  o  ?  6 


n  e  n  c!  (  ) 


pr  i  n 


1 1  f  <  " 
1 1  f  (  " 
1 1  f  C  " 
Itf  C " 
1 1  f  C  " 
Itf  C" 


modi  f  l  :  j  ‘..on  codes  :  \ n "  )  ; 

- \n\n "  )  ; 

modify  unit  percentage 
mo defy  unit  location 
modify  unit  plan  ..... 

.  .  i  f  y  command  unit  ... 
modify  instruction  numb 
end  of  modification  ... 


t\n")  ; 
l\n")  ; 
D\n" ) ; 

c  \  n  "  )  : 

i\r" J  ; 
e\n\n " ) 


reeter  =  true! 
suitchCcodaC 00) 

{ 

case  *  t '  : 

case  ' T  '  :  m o d i f  y _ p  e r  o 

br.aa  ’<  ; 

case  '  1  '  : 

case  ' L  '  :  modify  1. 


n  t  O  ; 


m  o  J  i  f 
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case  'C'  :  modify_command(); 
break; 


case  '  I  '  :  modify.ins’.O  J 
break; 

case  '  p  '  : 

case  '  P  '  :  modify_plan(); 
break; 

case  '  e  '  I 

case  'S'  :  reenter  =  false; 
j  r  e  a  k  ; 

case  ' f  '  :  break; 

default  5  orintfC"  unrecognised  inDut 
break ! 


try  again\n") 


if  CcocieCO:  !  =  'S'  it  codeCOD  !  =  'a') 

{ 

printfC"  Enter  modification  code  :  "); 
s:einf("U"*co{l3)  ; 
printf ("\n") ; 

> 

> 

jiili  (reenter  =  =  true); 
return; 


/  i  I  1.5.3  modify_percent  *  / 


mo  dole  \u-‘  5£r  : 

’..5.3 

MODULE  N A M E  l 

modi fy_per;ent 

=u notion  : 

modify  unit  parentage 

algorithm  : 

1  -  acceot  neua  percentage  (per) 

2  -  if  per  >  100  send  error  message  and  go 

to  step  1 

3  -  replace  percentage  of  the  unit  bey  per 

in  relation  UNIT. 

A  -  return 

:  ’  u  : 

par 

OUTPUTS  : 

messages 

3L05AL  V  A 

READ  !  xdep*  xlevel»  xt/j?,  xn_.~ 

3  L  0  5  A  L  V  4  P  I  A  5  L  5 

-  n  A G  E  0  5  none 

=  I  L  5  S  '  i  A  D  I 

none 

=  I ,  wPITTEN  : 

none 

-!  A  -1  _  *  A  R  E  INPUT 

:  n  o  n  a 

--PDWAPE  OUTPUT 

!  n  or  9 

C  H  LL  [  U  M  G  D  U  L  Z  5 

:  a  m  m  e  n  cl 

C  -  L  L  I  'i  j  MODULES 

;  none 

*  *  ,  :  ; 

:  LT  COL  G  A  5  E  R  A.  ELSnARAWY 

■  up  r 

:  Version  1.0  >  .■  :  Col  Saber  A.  Elsa 

A  : T / E  N  G  C  3  o  0  J  7  MAY  1 9  S  6 
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**int  per ; 
d  o 

£ 

printf( "Enter  new  percentage  5  "  )  5 
scanf("*3d",Cper)  l 
orintf C"\n") 5 
if  (per  <  101) 

£ 

**  range  of  u  is  unit 

replace  u  (percentage  =  c  e  r  ) 

*  *  where  u.dep  =  xdep  and  u. level  =  xle 

<  »  and  u.type=  xtype  and  u  .  n  u  r  =  xnum 

> 

9  1  S  0 

print f( "percentage  snould  be  <=  1 0 0 \ n " ) 5 


(per  >  100); 


r  e  t  u  r  n  ; 


1  .  5  .  A  .no  defy  location 


DATE 
V  E  R  S  I  C I 
•'  l  3  L  E 
‘•'JOULE 

:  'J  NC  T  I . 

i  l  ■ :  r  :  ■ 


:  j  m  a  v 
:  l.O 
N  J  v  E  E  R  : 
*<  a  *•'  E  : 


INPUTS 
0‘JTPUT 
SL  03  AL 

~  t  “»  ^  i 


0  -  L  L  E  0 
J  A  _  L  I  N 

; , ;  - :  r 

h  :  r  o  r 


1936 

1.5.4 

modify_loc?tion 

t.  o  cl  i  f  y  unit  location 

1  -  accept  n e j  locationCloc) 

1  -  if  tne  location  is  rot  correct  display 
an  error  -nessage  arc:  ;?  to  st-eo  1. 

3  -  modify  toy  unit  location  i  n  the  r  _•  1  a  1 1 
UNIT 

<♦  -  return. 

1  o  c 

error  messege 


VARIABLE 
V  A  R  I  A  3  L  E 
R  c  A  u  5 

WRITTEN  : 

■  INPUT 
RE  OUTPUT 
• '  0  0  U  L  E  S 
5  MODULES 


READ 

C  h  a  . 


x  d  e  p  t  xlevel.  xtype 


a  n  n  e  n  d 
r  j  n  c 

LT  COL  GA3EP  A.  ELShARAWY 
Version  1.0  by  Lt  Col  Gaber 
AFIT/EN  GCS  3  •>  J  7  MAY  1936 


Elsnarau/y 


n1*? 
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printfC" Enter  nsi  location  :  "); 

scanf C"«s", loc) ; 

printf ("\n”) ; 

if  C ( strlenC loc )  ==  1)  LI 

locCOS  ==  'a  '  ||  loc  CO  1  ==  'i>*  || 

locCOD  ==  'c  '  ||  locCOD  ==  'cl  '  |  | 

locCOD  ==  'a '  ||  locCGD  ==  'f ') 

{ 


range  of  u  is  unit 
replace  u( location  =  loc) 

jh era  u.deo  =  x  d  e  p  and  u.laval  =  x  1  e  y  e  1 
and  u.type=  xtypa  and  u  .  n  u  m  =  x  n  u  m 
roan  ter  =  falsa; 

> 

a  1  s  a 
{ 

print^C" Unrecognized  location  . \n"  ); 
reentar  =  true; 

> 


1 i  (r??nter  = 
n  I 


=  t  r  u  :- )  I 


1.5.5 


1  f  y  lost  / 


DAT z  :  7 

version  :  l . : 
M  0  D  L  Z  J  V  i  E  T 
MOGUL  E  \  A  E 
■  U  N  C  T  ID’. 

A l OCR  I  7 i* 


INPUTS  : 

outputs  : 

3  l  DEAL  V  A  ?.  I  A  3  L  £ 
3L  C£  A  L  V  A  R I  A 3 L  E 
=  I  LE  S  READ  ; 

- 1  L  S  5  «  R  E  T  T  £  r.  : 
HARDWARE  input 
MARDw-IRE  output 

:  A  ..LED  MODULES 
- «  L  L I  A  j  MOOULcS 
A'JToER 

-1 :  s  t  :  r  y 


1^5 


nocli  fy_inst 

nodify  unit  instruction  nj"i)?r. 

1  -  -occeot  nej  instruction  n  u  m  b  e  r  (  i  n 

2  -  if  ms  not  in  5  characters  disol 

an  error  message  and  go  to  steo 

3  -  modify  instruction  in  relation  U ' 

4  -  return 
in  st 
massage 

READ  1  ->  p  »  xlaval*  xtyp?»  xnum 


none 

:  a  mm  e  n  cl 
:  none 

:  LT  COL  GA3ER  A.  E 1 5  H  A  p  i  Y 
:  Version  1.0  0  y  Lt  Col  Caber  A.  Els 
A=IT/EN  GCS  3  6  J  1  MAY  1936 


h  a  r  a  jj  y 


1 1  f  y  _  i  n 


n  o 


it-  A* 
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printf  ("Enter  neu  instruction  nun  bar  :  "); 

scsnf(H?s"»ins); 

printf("\n*')  5 

it  Cstrlen(ins)  ==  5) 

{ 

range  of  u  13  unit 

replace  u(instruction  =  ins) 

jhere  u.deo  =  x  c!  e  p  and  u.laval  =  xlevel 
and  u  .  t  y  o  e  =  xtype  and  u.nun  =  xnun 
reenter  =  falsa; 

> 

a  1  s  a 
{ 

print  f(" instruction  nun bar  should  he  5  digitsXn" ) 
reenter  =  true; 

> 

> 

u/hile  (reenter  ==  true)  ! 


plan  =  fals 
cl  no  to  step 
_  o  1  "  n  -  t  r  j  e 
d  -go  to  step 


-  U  \  u  TI  -  :  modify  unit  o  1  a  n  (  s ) 

*l  3  Z < I T -  •  1  :  1  -  print  unit  ;lrn(s) 

2  -  ask  ;  tne  use'  to  enter  tne  r.-'H;t'ecl  o  c  e 
2  -  accaot  ooerption  :o:,e  and  plan  ran  a 

4  -  call  check.plan 

5  -  if  operation  is  d  and  check  plan  =  f  a 1 ■ 

display  an  error  .massage  and  go  to  sta: 

6  -  if  operation  is  i  and  check.pl • n  -  trj 

display  an  error  renege  arc1  g3  to  sta! 

7  -  return  juhen  tne  u  „  -  enter 

l  -  go  to  st  eo  2. 

I  'i  0  j  i  p  :  pptxoian 

1  ^  T  Q  U  T  S  :  error  messages 

5  A  L  VARIABLE  3 5  A  2  :  xclaof  xleveli  x  t  /  c  a  »  xnum,  xolan 

B  A L  VARIABLE  C  h  A N G E  0  :  Ian 

;  -  L  E  3  3  E  A  C  .  none 
=  I L  E  S  written  :  none 
-  O  W  A  3  S  INPUT  :  none 

1  A  O  W  4  3  E  jUTPUT;  none 

2  A  L  L  E  C  M2CULES  :  amend 

3  A  L  L  I  *;  3  M  C  C  J  L  E  S  :  cheok.olnn 

I'jTri?  :  L  T  CTL  :-A3Eh  1 .  5 L  5  { 

'  3  T  1  r  :  V  a  r  si:'  1.0  by  L  t  Col  Gabpr  a.  Elsrorajjy 


:  cl  a  Of  xleveli  x  t  /  c  a  * 


xolan 


May  2  2  10150  1986  o  a)  a  e  cl .  q  Pagi  24 


■nod  i  f  y_p  1  an  () 

( 

int  raanterl  ; 

*«  char  odl20J 
**  rang  a  of  p  is  plan 

printfC"Tha  unit  is  in  the  folio x-ing  planCs)  :  \  n  "  )  : 

**  retrieve  into  unitplans(p.plan) 

inhere  p.deo  =  xdao  and  d. level  =  xlavel 
**  and  p.type  =  xtyoa  and  D.nun  =  xnun 
**  print  unitplans 
*3  destroy  unitolans 

printfC" Modification  nay  oe  dona  tnrou  ,  h  2  operations'^"); 

C^intf  ("insertion  (i)  or  deletion  Cd).  it  and  p'-mt  ' *'\n"  ); 

reenterl  =  true! 


*  « 
a  * 


1 1 
i  4 


{ 

pnintf  ("Enter  ooeration  coda  C  ci  / 1  )  :  "); 

scenf ("ta",op); 
pr.ntrC11  \  n")  ; 

if ( 00  CO]  ==  'I'  II  OP  CO]  ==  '1 '  || 
oo'  C]  ==  '0 '  II  odCC  D  ==  '  d  ' ) 

{ 

on.-Vj  ("Enter  plan  t  "  )  ; 

3  c  ?  n  f  (  "  i  j  "  i  *  p  1  a  n  ) ; 
ormtf  ("\n")! 


S'jitcn(j;; 

( 

c  a  s  ? 

cap. 


case  'i' 
c  a sa  '  I  ' 


case  '  -f  ' 
data- 


> 

> 

tuhilaCreente-i 


if  (cneck.planO  =  -  *  a  1 1.  e  ) 

pninTf(''Tni;  jn.t  is  "et  :n  tni  s  olan\n"  )5 
a  1  s  a 
C 

d  a  1  a  t  a  p  nhereCc.ciep  =  xclas  and  p.  level  =  xlavel 
and  o. type  =  xty: ?  and  p . o 1 ? n  =  xplan) 

> 

0  r  a  a  <  ; 

if  (check.planO  ==  true) 

printfC "The  unit  is  already  in  this  p  1  a  n  \  n  "  )  ; 
else 
{ 

if  (cn  •>cK_clanid()  ==  falsa) 

printfC" Unrecognised  clan\n")  ! 
else 

eopend  to  planCd J>-<Uepf la vel=xlavel*type=x type* 
n  u  t.  =  x  n  u  n  ,  plan=xplan) 

> 

la  r  a  a  '< 

reante •(  =  falsa; 

braax; 

P'-intf  ("Jnri-cogni:  i  .  t  \  n  "  )  ; 


-  -  j  ? ) ; 
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raturn  ; 

> 


/*  ||  1.5. 2.1 

cneck_olan  s?  / 

DATE  I  7  MAY  1986 

VERSION  :  1.0 

MODULE  NUMBER 

:  l . 5. 2.  l 

MODULE  NAME 

:  check_plan 

= UNCTION 

:  check  the  entered  unit 

plan 

ALGORITHM 

t  1  -  if  unit  plan  exist 
return(true) 

in  tne  relation  P  l  A  N 

2  -  if  not  raturn(falsa) 

INGOTS 

:  unit  olan(xplan),  unit 

codeCxdeG*<level*xtype,xnum) 

:  J  T  P  U  T  s  : 

1  o  r  0 

jLJoAL  VARIABLE 

READ 

:  x  d  e  p  *  x  1  a  v  3  i  »  x  t  y  p  a  »  xnunf 

GL03AL  VARIABLE 

CHANGED 

!  no n  3 

=ILES  READ  : 

none 

=ILES  WRITTEN  : 

none 

HARDWARE  INPUT 

:  none 

HARDWARE  OUTPUT 

:  none 

“  A  L  L  5  5  MODULES  :  modify_plan 
CALLING  MODULES  :  none 

A  U  T  h  E  R  ;  LT  COL  G  A  3  E  R  A.  ELShA.RAWY 

n  I  5  7  C  R  Y  :  Version  1.0  lay  L  t  Col  Saber  A.  Els">arau<y 

A- IT/ EM  CCS  So J  7  M  A  Y  193b 


: n eck_clan(  ) 

X 

<  »  c  n  a  r  n cl  .■  '  i  1  ,  olevelC3J»  ntyp?C3D»  nnumC«]*rplanC23: 

*  *  range  of  o  is  clan 

i  <t  retriave(-idap  =  p.dao*  nlevel-p.level*  ntyc3-c.type» 

“=»  nnum=p.num,  nplan=p.plan) 

*  «  n  h  a  r  e  o.dep  =  x  d  e  p  and  p. level  =  x  1  e  v  e  1 

*  *  ana  o.t/oe=xtype  and  p.pian  =  xplan 

ifCstrcmoCxdepfnciep)  ==  0 

SO  strcmoC xlevel »r level)  =  *  0 

ZL  3trcmp(xtyo?,ntyD?)  =  -  0 

•IE  strcmoCx-  '-.n-ibn)  ==  0 

SC  s  t  r  c  m  p  (  x  p  •  ,  o  p  1  a  n  )  ==  0) 

re  turn(truj)  l 
els? 

raturn(false); 

> 

/  II  1.5.1  m  o  d  i  *  y  _  c  o  m  m  a  n  d  5  / 

/  ;• - I - 

/•::  :  7  MAY  1936 

VERSION  :  1.0 

MODULE  NUMBER  :  1.5.1 

MODULE  NAME  :  rno;,.fy_com^and 

=UNCTI0n  :  modify  command  unit 

ALGORITHM  :  1  -  save  unit  c  -  •!  •?  (  x  d  ?  p  i  •»  \  ?  v  e  1  ,  x  t  y  p  a  ,  x  n  u  "  Y 
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INPUTS 
OUTPUTS 
3  L  0  E  A  L 
3LD3 AL 
=  I  L  E  S  P 
-  I  L  E  S  W 
-UPDrtAP 
-(  A  P  D  U  A  P 
CALLED 
CALL  INS 
A  J  Tn  E  0 
-t  I  ST  CP  Y 


2  -  call  gst.uni t_eode  to  accept  command 

unit  code 

3  -  call  check_unit_code 

4  -  if  c heck_uni t_code  =  false  display  an  error 

message  and  a  s  '<  e  tne  user  if  he  uants  to  try 
again,  go  to  steo  2  if  the  responce  is  "y" 
go  to  steo  6  other ii'isa. 

5  -  replace  the  command  unit  witn  the  neuj  data  in 

tne  relation  COMMAND. 

6  -  restore  unit  code. 

7  -  return. 

^command  unit  code. 

error  messages 


VAfc I  A  3  L  E 
VARIABLE 
E  AC  : 
P  I  T  T  E  N  : 
c  INPUT 
E  CUT  PUT 
MODULES 
MODULES 


READ  :  xdeo,  xlevel*  xtypa*  xnum 

CHANCED  :  .none 
none 
none 
none 
none 

:  a  m  m  e  n  cl 

:  get_unit_cocle»  cneck_unit_code 
:  LT  COL  GA3ER  A.  ELSHAPAwY 
:  V.rsion  1.0  by  Lt  Col  Sauer  A. 
AFIT/SN  CCS  3  6  J  7  MAY  1936 


char  d  cl  ;■  C  3  0  »  dlevelC30*  d  t  y  ,e  e  1  3  C  .  c!  n  u  r  C  4  j  ; 
1  n  t  reence-2; 
c  ai  r>  n  5  w  «.  1  • 

/  save  uni*,  data  *  / 
s  t  r  c  o y  I  dc‘  e p  *  x d e  p  )  i 
strcpy(dlevel*xl?vel); 
strcoyCdtype*  xtype)  \ 
strcoy(dnumfxnum); 


o  r  i  n  t  f  C  "  •_  n  t  er  neu  command  unit  cl  a  t :  V 
;et_unit_C0daC)  \ 
if  (cnjck_unit_cocie()  ==  false) 

{ 

printfC'Tnis  unit  is  not  axistNn"); 
o>-  i  n  :  f  (  "  Do  you  want  to  try  again  (y/n) 
sc3PfC"?s",ans>; 

orin  t  f (" \n"  )  5 
if(ansC33  ==  'y') 

r  e  e - t  ’ r 2  ==  t - u  ? ; 
else 

reenterZ  ==  false: 

> 

e  1  s  ;• 

( 


i  f  C  X 


false; 

:!'!■> n  Li  xlevel  ~  *  :!  1  1  >/  ■> 
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xtype==dtype  6  S  xnum  = 

f 

=  d  n  u  m  ) 

\ 

printfC" The  unit  can  not 
> 

else 

{ 

command 

itself 

4  9 

range  of  c  is  command 

9  9 

replace  c  Ccdeo  =  x d e o ♦ 

c  1  e  v  e  1  = 

xlevel, 

4  4 

ctyoe=xtype, 

c  r,  u  m  = 

xnum) 

4  9 

oihere  c.ciep  =  ddep  and 

c  .  1  e  v  e  1 

=  d  1  e  v  e  1 

4  4 

and  c.type=dtype  and 

C  .  num 

=  d  n  u  m 

/# 

Pestore  unit  data  * / 

strcpyCxdep*ddap); 
strcpyCxlevel , d level) ; 
strcoyCxtype,dtype); 
strcpy(xnum,dnum); 

> 

> 

> 

jhile(reenter2  =  =  trj-)  i 
r  e  t  u  r  n  : 

> 


/ *  II  1.7  h ?  i  n 
- 

date  :  7  may 
V  =  R  a  I  3  '«  :  1.0 
module  j  *•  =  =  r  : 

M C DOLE  NAME  : 

=jnctid%  : 

A  L  3  u  R  I  7  n  : 


inputs  : 

DOT  puts  : 

S'- DEAL  VARIABLE 
GLOBAL  VARIABLE 
PILES  READ  I 
'll.  ES  WRITTEN  : 
'  '•  1  0  W  A  R  E  I  N  3  J  T 
n  -  R  0  w  A  R  E  OUTPUT 
OALlEj  MODULES 

call:*.  :•  modules 

AO” 1:» 

,  r :  r  r 


*  / 


IS  oo 


1.  7 


ratriev  j 

retneva  unit  data 

i  -  retrieve  comsn :i  unit  code  trosi  the  relation 
C  0  M  M  A  N  0 


2 

3 


retrieve 
from  the 
retrieve 
relation 
retrieve 


percentage#  location, and  instruction 
relation  UNIT 

the  sum  of  unit  personnel  from  the 
ASSIGN? 

unit  name,  Balance  from  the  relation 


UN  IT. MUD  EL 


5  -  retrieve  unit  olanCs)  from  the  relation  plan 

6  -  display  the  unit  data 

7  -  return, 
unit  code, 
unit  data. 

READ  :  xdop,  xlevel,  xtype,  xnum 

CHANGED  :  /dap,  y level*  ytype*  ynum 


none 


none 
:  none 
:  non  j 


main 

rone 

L T  COL  G  A  =  E  R  A .  E  L  S -  * R  A  W Y 
V  .-.-lion  1.0  by  L  t  •“  1  Co  b  e  r  A .  El 
A  r  :  •  -•  =  N  G  :  G  3  -j  J  7  ■  Y  19  8  6 


of  a  p 
of  c 


’riav"i>  ) 

char  rnair.  eC31D*rbalenceC2J*  r  1  o  c  a  t  i 
int  rpar,  sump; 
ranji  of  u  is  un.t 
range  of  um  is  unit model 
range  of  p  is  plan 
range  of  ap  is  assigno 
range  of  c  is  command 
retrieveCydep  =  c  .  c  cl  e  o  *  yleval=c.cl 
ynum  =  c.cnem) 

j  n  ~  r  i  c.dep  =  xc'3p  an  cl  c.l?vel=xle 
and  c.tyoe  =  xtyoe  anc;  c.num  = 
retrieveCrnama  =  um. n  a me*r  balance  = 
u  n  o  r  e  um.deo  =  xclec  and  um.level=xlev 
anc1  um. type  =  xtyoe 
r e t r is va ( r p er  =  u . p e r c e n t a g e »  rloca 
rinstruction  =  u. instruct! 
i-'ere  u.dep  =  xdeo  and  u. level  =  xl 
a  n  o  u.type=xtype  and  u.num  =  xnum 
retrieve  into  ttempoCap.all) 

.n?r;  ao.deo  =  xdep  and  ao.levcl=xl 
a  n  ci  a  o  .  t  /  p  •  =  x  t  /  P'j 
range  of  tt  is  ttemoo 
refiev'Csumo  =  sunCtt.num)) 
c  ?  s  t  r  a  /  1 1 3  m  p  p 
o - l r t f C " T  h  E  UNIT  "  )  ; 

0  1  n  ♦  *  C  "  l  S  "  »  X  Cl  a  P  )  ; 

3  r  1  >  C  f  C  "  /  "  >  ; 
p  »■  i  n  t  f  C  "  %  s  "  »  x  1  e  v  e  1  )  ; 
p  r  i  n  t  f  C  "  /  "  )  ; 

3rintf("?s"»xtype); 

pr:ntj("/"); 

printfC" £  s  "  *  x  n  u  m  )  ; 

orintfC"  DATA  I  \ n \ n "  )  ; 

printfC"  UNIT  name  :  " 

p  r  i  n  t  f  1  i  s 11  t  r  n  a  m  o  )  ; 

print  f("\n"  ); 

printfC”  UNIT  LOCATION  .*  "),* 

p  -  .  n  t  f  (  "  1  s  "  •  r  1  o  c  a  t  i  o  n  )  J 
e  r  i  '  t  f  c  ”  \  n  "  )  ; 

p  r  i  ~  t  f  ( *•  Instruction  9  : 

printfC"  is"  ,  rir,  struction); 
printfC  ”  \n  "  )  ; 

printfC"  UNIT  BALANCE  :  "); 

printfC "is"»r balance)  ; 
printfC "\n"  )  5 

printfC"  PERCENTAGE  l  "); 

printfC"  ,jcl"(rp>r); 
printfC " \n"  )  ; 

printfC"  P£  R  S  i  <  <  _  : 

print  f  C  "  C3cl"*Sump); 
printfC"  \n"); 

ifCxlevell-jJ  '  0  '  \  .  xlevelCll 

■  mtf  ("Tm  j  is  t'*  h  i  j  h  n  t  com- 
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e  1  s  a 

i 

printf ("COMMAND  UNIT  C23E  :  "): 

printfC  "%s"»yc!eo)  ; 

orintf ("/") ; 

printfC”  SJs"*ylaVv.-l); 

printfC"/"): 

printfC "  %  s  " .  y  t  y  p  a  ) ; 

printfC"/"); 

printfC"?s"iynu.ii)  5 

printfC"  \n\n" ) ; 

> 

printfC "THE  UNIT  IS  IN  T  n  £  PLANCs) 

*  *  ratriava  into  umtpia.nsCp.plan) 

J!  dinar  3  p.dap=xdap  and  p.laval=xlavel 

*  *  and  p.typa=xty?e  and  p.nun=xnum 

*  *  print  unitplans 

*  *  destroy  unitplans 

printfC" \n")I 


RAM  DMA 


T/5N/3CS  S  6  J 


R 


Appendix  H 

Test  Results  for  the  Edit  Program 


O 
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cript  startici  on  Tue  May  13  12:  5  9  1  1  2  1986 
o  m  a  9  d 

ailing  ingras 


A  MM  E ‘.DING  UNITS  DATA 


COMMAND  summery  ; 


I  .......  Insert  nen  unit. 

0  .......  Delete  an  existing  unit. 

A  .......  A  m  m  e  n  ci  an  existing  unit  data. 

R  .  Retrieve  an  existing  unit  data 


n  .  HelpCdisoiay  command  sugary). 

5  .  Exit  to  UNIX. 

Inter  command  =  =  >  r 


I  n  t  e  •*  unit  code  : 

department  =>  10 

level  =====r>  10C 

type  ==-  =  =  ---•>  130 

n  _  -bar  =  =  =:•-■•>  10 

T  e  key  f  p  i.'ould  be  c  2  »  c  2  >  c  3 

To  exit  print  3 
department  =>  10 

level  =====->  10 

tyoe  =======>  13 

number  -  =  100 

T'l?  unit  is  not  exist 
iNTcR  COMMAND 


Inter  unit  code  ! 


department  =  >  10 
level  05 

ty a  *  -  - =  -  -  ;  0  3 

number  =  =  =  =  -  N  Oil 
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level  === 

-  =  =  > 

05 

type  ==== 

=  =  =  > 

02 

number  == 

=  =  =  > 

200 

THE  UNIT  10/05/02/200  DATA  : 


UNIT  NAME 
UNIT  LOCATION 
INSTRUCTION  » 
UNIT  3ALANCE 
PERCENTAGE 
PERSONNEL  * 
COMM  AND  UNIT  CODE 

T  -i  S  UNIT  IS  IN  THE 


:  infantry  brigade 
:  c 

:  3  02  00 

a 

•  L. 

:  3  5 

:  63 

:  oi/oo/co/ooo 

r  L  A  N  C  3  )  : 


unite! a ns  relation 


I  o  1  a  n  | 


I  o 


I 


3  =  =  >  3 


E  n  x  e  *"  -nit  cone  : 
department  -  >  10 
level  ======>  05 

tyoe  =  =  =  =  =  =  =  >  02 
number  =  =  =  =  =  >  200 
Are  you  3  u  r  e  (y/n)  y 

Go  /  -  x  a  n  t  to  delete  all  subunits  (y/n)  y 

INTER  COMMA*,  0  =  =  >  r 


i~  \  >r  unit  code  : 
department  =>  10 
L  ■>  v  ■  1  =  =  =  =  =  =  >  Co 
t y  .  -  =  =  =  =•>  02 

number  =====>  200 


i 
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INTER  command  ==>  r 

Enter  unit  code  : 

department  =>  10 

level  ======>  06 

type  =======>  03 

number  =====>  020 

Tnis  unit  is  not  exist 
INTER  COMMAND  =  =  >  r 

Enter  unit  c  o  ci  e  : 

:leo?rt -  -"it  =>  10 
level  ======>  06 

t / P 3  ====r==>  03 

numuer  =====>  021 

T  r i s  unit  is  not  exist 

:\t:~  d  =  =  >  r 

AM MENDING  UNITS  DATA 

CD  MMA  NO  $UMy  r  ••  '  : 

I  .  Insert  n?j  unit. 

l  .  Delete  an  rusting  unit. 

A  .  An  mend  an  •■isting  unit  data. 

R  .  Retriev  ■  n  justing  unit  data 

H  .  HelpCdwOl?/  conn-n  j  summer/). 

E  .  Exit  to  UNIX. 
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type  =======>  03 

number  =====>  Oil 

THE  UNIT  10/06/03/011  DATA  : 

UNIT  NAME  :  infantry  battalion 

UNIT  LOCATION  :  b 
INSTRUCTION  *  :  30100 
UNIT  BALANCE  :  2 
PERCENTAGE  :  90 

PERSONNEL  s  :  350 
COMMAND  UNIT  CODE  :  10/05/C2/1CD 

THE  UNIT  IS  IN  THE  R LANCs)  : 


unitplans  r 

e  1  a 

1 1  on 

1  c  1  a  n  | 

1 -  -  1 

1  b  1 

Ic  | 

I - | 

INTER  COMMA 

NO 

II 

II 

V 

•1> 

Enter  unit 

code  : 

d3  3c.rt.riit 

=  > 

1  0 

level  ===== 

=  > 

C  5 

tyoe  ====== 

=  > 

03 

n  u  n  b  3  r  =  =  =  = 

=  > 

011 

modification  codes  : 

modify  unit  percentage  ....  t 

■i  o  :!  »  f  y  unit  location  .....  1 

~..:ify  unit  plan  .........  p 

•ti  :  ..  .  •  /  connanc!  unit  .......  c 

modify  instruction  number.,  i 
end  of  modification  .......  e 


:  n  *  -.r  ,t.  onification  code  :  t 
Enti’-  nejj  percentage  :  50 
Enter  modification  coda  :  1 


Enter  n  e  u  lr. 
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Enter  non  location  :  f 
Enter  modification  code  :  d 
The  unit  is  in  tna  following  plan(s)  : 
unitDlans  relation 
I  0 1  on  | 

I - I 

ID  I 

lc  | 

| - | 

Modification  may  be  done  through  2  operations 
i  n  3  v  r  t  i  o  n  C  i  )  or  deletion  (  d  )  .  ‘  A  t  ?r:l  print  ' 
Enter  operation  code  (  d  /  i  )  :  d 

inter  olan  :  b 

Enter  operation  code  (  d  / 1 )  :  i 

Enter  olan  :  d 

inter  operation  code  (d/i)  :  i 

Enter  olan  J  i 
Jn recognized  plan 

Enter  opa.'.tion  cede  (d/i)  J  i 

inter  p.jn  :  a 

inter  operation  code  (d/i)  :  * 

inter  modification  code  :  c 

Enter  njuj  command  unit  data  : 
department  =>  10 

level  ======>  01 

tr  ;  =======>  go 

n  u m  o a  r  =  =  =  =  =  >  00) 

Enter  modification  code  :  l 

..r  neu  instruction  number  :  70001 

Enter  modification  code  :  e 

INTER  COM  vi,  NO  =  =  >  r 

Enter  unit  C V  ■  : 
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department  =>  10 

level  ======>  06 

tyoe  ====-==>  03 

number  =====>  Oil 

T  h  5  UNIT  1  0/06/03/01  1  OAT A  : 

UNIT  .NAME  :  infantry  oattalion 

UNIT  LOCATION  :  f 
INSTRUCTION  *  :  70001 
UNIT  BALANCE  :  2 
PERCENTAGE  :  50 

PERSONNEL  a  :  350 
COMMAND  UNIT  CODE  :  10/01/00/000 

TriE  unit  is  in  THE  PLANCs)  : 

unitplans  relation 

t  p  1  an  | 

I - | 

I  a  I 

I  c  I 

I  Ci  I 


INTER  COMMAND  =  =  >  M 


A  M  M  5  '1 0  I  ’■!  Z  UNITS  DATA 


COMMA  ",  0  5  .  ;  m  =  S  Y  : 


I  .  Insert  nasu  unit. 

0  .  Delete  an  existing  unit. 

A  .  Am  men  cl  an  existing  unit  data. 

R  .......  Retrieve  an  existing  unit  data. 

H  .  H  ■  1  r  cl  i  s  p  1  a  y  command  summery). 

E  .......  "'^.t  to  UNIX. 

INTER  CC  A  NO  =  =  >  I 


unit  cod 
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type  =======>  02 

number  =====>  590 

:nt<jr  unit  data  t 
3ercant  age  !  1 5 

Location  :  c! 

Instruction  muo^r  :  7  0  9  91 

enter  olan(s),  at  end  print  '  v ' 

Defense  olan  :  a 

Defense  olan  :  b 

Defense  olan  :  c 

Defense  olan  :  $« 

Inter  ccn-i  an  cl  unit  data  : 
department  =>  01 


level  ======>  90 

tyoe  =======>  90 

n  ■_  "  e  e  r  =  =  =-•>  909 


COMMAND  =  =  >  a 


Inter  unit 

code  ! 

:l  e  o  a  '  t  n  e  **  t 

-  *  -j 

l  '•  /  ■  1  =  =  =  = 

-  =  >  ID 

tyoe  ===== 

=  =  >  02 

rjtiij  ;*r  =  =  = 

=  =  >  500 

T H  5  UNIT  19/  9  5/  02/500 

UNIT  NAME  :  infantry  brigade 

UNIT  LOCATION  :  d 
INSTn.D'IJN  «  :  70901 

UNIT  3  A  _  A  N  C  I  :  2 
3  -  .-MAGE  :  7  5 

PERSONNEL  # 

:  I  AND  UNIT  CQC5 


./  J/00  0 
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THE  UNIT  IS  IN  THE  3LAN(s)  I 
unitplans  relation 
I pl an  | 

I - I 

la  I 

lb  | 

lc  i 

I - , 

INTER  COMMAND  ==>  I 

Enter  unit  c;Ji  : 
department  =>  11 
level  ======>  06 

type  =======>  11 

n u  n b  e  r  =-  =  =  =  >  111 

0  o  y  o  u  jj  a  n  t  to  insert  a  n  e  i  unit  model  (  y  /  n  ) 
Enter  unit  r  p  ■:!  a  1  da*.?  J 

n 

-  -J 

name  :  rj]  t  a  n  <  battalion 

)  a  1  a  n  :  :  2 

Insert  o  e  r  s  s  -  '  1  :!  a  t  a  1 

I  a  t  and  print  '  * '  ) 


Person 

deee-tment 

• 

• 

11 

3  i  r  $  o  n 

speciality 

• 

• 

off 

'J  Li  1\ ')  ^  r 

of  pe-sonnel 

:  20 

3  <*  r  S  0  n 

cl  a  p  a  r  t  m  _•  n  t 

10 

3  ;■  r  s  o  n 

speciality 

• 

sec 

’■lumber 

of  oerson 

,  T 

:  1  3 

3  s  r  3  c  n 

dap  a  r  t  m  e  n  t 

• 

• 

1 1 

3  P  r  s  C  n 

speciality 

• 

• 

dr  i 

'4  u  u  1)  a  r 

o:  person"' 

:  30 

■  -  son 

d  e;  ar  t  m  ;• - 

• 

• 

1 1 

.  ,1 

speciality 

• 

• 

com 
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Dunbar  of  personnel  :  150 

5irson  pap artment  : 

Insert  armmament  data  : 

(at  end  print  '  ) 

Arm  department  :  10 

C 

Iru  name  :  pistol  9  mm 
Nonpar  of  arms  :  200 
Arm  aepartmant  :  10 
C 

Arm  name  :  machineeaaee  gunnnnn 

iuTa.-r  of  arms  :  12 

J  n  m  ?  c  n  a  c!  department  /  arm  name 
Arm  department  :  4  §  c  n  i  n  e  gun 

r 

Arm  nan-.  :  machine?  gunn 

N umber  zf  • r m  s  :  12 

Jnmacn-eti  department  /  arm  name 

Arm  dec  ■  ‘lent  :  10 

C 

Arm  name  :  r  a  c  n  i  n  e  gun 
Number  of  arms  :  12 
Arm  d e  o :  - t  1  «n  t  :  11 

C 

Arm  name  :  tank  m  6  0  a3 
'iu'^Ieer  of  arms  :  32 
A  r  i  d  e  p  a  r  t  m  e  n  t  :  * 

enter  unit  data  : 

Percent  ■  :  •  :  9  0 

L  j  .  U  n  t  u 

In-,*~uctipn  number  :  7  '  ’  '  •’ 

'  +  *  r  pi.  "  ,  ,  at  -e  print  *  *  * 
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Defense  plan  :  a 
Defense  plan  :  ii 
Defense  olan  :  * 

Inter  command  unit  data  : 
department  =>  10 
level  ======>  05 

type  =======>  02 

number  =====>  500 

I  NT £9  COMMAND  =  =  >  r 

:nt«"  unit  code  : 

:l  e  c  r  t  m  e  n  t  =  >  11 

level  ======>  05 

tyo  .■  =  =  =  =  =  =  =  >  1  i 

n u m i)  ? r  ==-  =  =  >  111 

THE  UNIT  11/06/11/111  DATA  ; 

UNIT  NAME  :  m50  tank  Nattal 

UNIT  LOCATION  :  b 

I  N  S  T  ?  'J  0  r  I  D  N  t  5  7  0  0  0  2 

UNIT  BALANCE  :  2 

P=kCSNThO=  :  90 

P£?S3NN=u  *  :  215 

co-r'...'.:  ‘  :■£  :  10/05/02/500 

THE  UNIT  15  IN  THE  PLANCs)  : 
jnitplanj  r e  1  .  1 

I  0  1  •'  n  | 

I  a  I 

I  >  I 

I - 1 

:  ■  ■  r  ->  COMMAND  =  =  >  H 
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A MM  ENDING  UNITS  DATA 


COMMAND  SUMMEPY  : 


I  .......  Insert  neu  unit. 

J  .......  Delate  an  existing  unit. 

A  .  A  m  a  e  n  d  an  existing  unit  data. 

S  .  Retrieve  an  existing  unit  data. 

M  .  HelpC  display  c  o  -tit,  a  n  d  summery). 

E  .  Exit  to  UN' IX. 

I  NTS  3  COMMAND  ==>  e 


G  0  C  0  5  A  Y  COME  AGAIN 
i  in ;r?s  o n a d p 


INGRES  version  7.10 

(10/27/31)  login 

T  u  e  May  13  13:17:10 

1  9  S  o 

;  o 

3  o  r  i  n  t  unifnodel 

»*»  v  — 

*•'  '  * 

:x?cut:n;  •  •  • 

unit 

"  o  d  e  1  r 

elation 

1  dec 

I  lev 

*  1  1 1  y  p  e 

1  n  a  t  ? 

1  b  a  1  ?  n  c 

i 

101 

I  0  0 

1  0  3 

1  nod 

11 

1  10 

l  : 

1  OC 

(infantry  dap 

1  1 

1 1 1 

1  0  1 

1  c  0 

lartiour  dep 

11 

1  16 

1  01 

1  0  3 

(signal  corp  :iao 

1  1 

ID 

105 

102 

linfantry  brigade 

12 

110 

106 

1  0  3 

| infantry  battalion 

1  2 

1 1 1 

1  Go 

1  07 

(tank  battalion 

12 

111 

1  --- 

1  36 

111 

1  m  6  0  tank  battalion 

1  2 

C  ■  t 

1  n  j  ? 

■  f-  print  a  s  s 
\ 

i  gn  o 

—  ,i 

)  * ing  . 

•  • 

?  > 

,  1  g  n  p  r  a  1 

a  1 1  o  n 

1 

-  p  1  1  ■  v 

:  1  t  y  o  e 

1  P  d  ?  p 

(spec  | nun 

1 

I  “ 

t 

!  3  '• 

j 

HO 

1  of  f  | 

32  1 

1  ' 

-  133 

i  : 

i  1C 

|  .  .  -  | 

52  1 

i 

1  0  0 

10  3 

1  10 

1  c.  1 

33  1 

i 

1  I  J  3 

1 

1  10 

1  d  r  i  | 

16  1 

1  o 

1  3  3 

;  • 

1  10 

1  c  r  a  1 

‘  1 

1  : 

1  ' 

!  '0 

111 

1  o  f  f  j 

21  1 
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116 

101 

1  00 

110 

(automatic  rifle 

1  1  6 

101 

100 

1  10 

1 t  r  uck  4x4  3  tons 

1  10 

1  C  5 

102 

1  10 

(automatic  rifle 

1  10 

1  05 

102 

110 

| machine  gun 

no 

105 

102 

1  11 

1 m 1 1 2  a2 

110 

105 

102 

110 

1 j  e  ep  4x4 

110 

105 

102 

110 

(truck  4x4  5  tons 

111 

1  06 

107 

1  10 

(pistol  5  mm 

111 

1  06 

107 

111 

Itank  m63  a3 

111 

106 

107 

110 

| j  a  a  p  4x4 

1 1 1 

1  0  6 

107 

110 

| truck  4x4  3  tons 

1 1 1 

1  06 

111 

1  10 

(pistol  9  m-n 

111 

1  06 

111 

1  10 

Imacbine  gun 

1 11 
* 

1  06 

111 

111 

Itank  m6  0  a3 

continue 
$  print  unit 

Executing  .  .  . 


unit  relation 


1  Cl  3  P 

1  level 

i  t  y  p  a 

I n  u  m  leer 

centaga  | 1 oc a t i I i n s t r u | 

1 

I  0  1 

100 

1  00 

10  0  0  1 

1  0  0  1  a 

110001  | 

1  1  0 

101 

100 

1  0  0  0  I 

7  C  |  a 

120010  | 

111 

1  o  1 

1  00 

10  0  0  1 

7  0  1a 

120011  1 

1  1  6 

1  j  1 

100 

1  ?  0  0  1 

70  1a 

120016  | 

1  1  o 

1  05 

1  C  2 

110  0  1 

9  0  1  b 

130100  I 

110 

1  0  5 

102 

1  5  0  0  I 

7  5  I  cl 

170001  I 

1 1 1 

1  Oo 

111 

1  1  11  1 

90  1  b 

170002  I 

no 

1  06 

103 

1011  I 

50  1  f 

170001  | 

1 11 

1 - 

1  06 

107 

1100  1 

90  1  b 

140100  I 

continue 
-  p  r  1  n  t  p  1  r. 

*  \p 

executin'])  . 


o'  relation 


1  cl  a  p 

1  level 

I  *  y  p  e 

1  nun 

1  0  1 

100 

|  u  0 

1000 

1  0  1 

1  u0 

100 

1  000 

!  ■)  1 

I  0  0 

|00 

100  0 

1  1  o 

1  0  1 

100 

1  000 

.  1 1 

i 

103 

10  0  0 

1  1 

1  M 

I  O' 

1  o :  o 

1  i 

i  '  5 

1  : 

1100 

, 

1 

1100 

I  p  1  an 


a 

b 

a 

a 


0 


a 

b 
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110 

1  36 

1  03 

1011 

1  3 

1  10 

105 

102 

1  500 

1  a 

110 

I  06 

103 

1011 

lc 

111 

106 

107 

1  100 

1  b 

111 

I  06 

107 

1100 

lc 

1 10 

105 

102 

1  500 

1  b 

113 

105 

1  02 

1  500 

lc 

111 

1  36 

111 

1  111 

I  cl 

111 

I  0  6 

111 

1111 

lb 

I 


c o  n  t in  u 

1 3 

t  or  in  t 

C  O  n  t  a  n  cl 

s  \S 

-x’Cuting  .  . 

• 

;  o  a  Ti  a  n  cl 

re  lat 

i  on 

1  c  cl  e  o 

|  _  _ 

1  c  1  9  V  3 

1  1  c  t  y  o  e 

|  cnun 

1  ci  ep 

I  1  e  v  e  1 

1  typ 

i  oi 

i  00 

1  0  3 

1000 

1  1  0 

1  01 

103 

1  0  1 

1  0  0 

100 

1030 

1  1  1 

1  01 

1  0  3 

1  31 

1  33 

1  0  0 

1000 

116 

1  01 

103 

1  0  1 

100 

1  3  0 

1  J33 

lie 

105 

1  02 

101 

1  0  0 

1  CO 

10  3  0 

110 

1  33 

1  02 

1  1  3 

1  3  5 

1  0  2 

150  3 

111 

1  0d 

111 

!  1  3 

1  01 

1  0  0 

loco 

1  1  0 

1  C  6 

1  0  3 

1  10 

!  3  5 

102 

1100 

1  1  1 

1  0  6 

1C’ 

i 

i 


contin^  _■ 

::  \a 

iNjPES  v9r?i:i  7.10  (10/27/31)  logout 
T  u  3  H  ?  y  l  .3:19136  1936 
good  3  y  :■  y  b  ~  ?r  ?.  jy  —  cone  again 
•> 

sc  riot  :  on  Tue  May  13  13: 1 9:^2  1 9 


|  nun 


I  00  3 
100  3 
10  00 

I  10C 
1500 
I  111 
I  311 
110  3 


Figure 


Figure 


Figure 


Figure  I- 


Pistol  9  mm  79 
Automatic  Rifle  100 
Jeep  4x4  6 
Truck  4x4-3  Tons  4 

-8.  Armament  Table  for  MOD  Code  01/00/00 


Pistol  9  mm 

30 

Automatic  Rifle 

40 

Truck  4x4-3  tons 

5 

-9.  Armament  Table  for  Infantry 

Department 

Code  10/01/00 

Pistol  9  mm 

30 

Automatic  Rifle 

41 

Truck  4x4-3  tons 

5 

I  —  1 0 .  Armament  Table 

for  Armor 

Department 

Code  11/01/00 

Pistol  Gun 

20 

Automatic  Rifle 

14 

Truck  4x4-3  tons 

4 

1.  Armament  Table  for 

Signal  Corp  Departme 

Code  16/01/00 

Pistol  9  mm 

28 

Automatic  Ri  f  1 

40 

Jeep  4x4 

12 

Truck  4x4-9  tons 

16 

Wireless  Set  R  240 

2 

1-12 . 


Armament  TAble  for  Infantry  Brigade 
Code  10/05/02 


Automatic  Rifle  330 
Machine  Gun  20 
M  113  -  A2  20 
Jeep  4x4  12 
Truck  4x4-5  tons  8 

Figure  1-13.  Armament  Table  for  Infantry  Battalion 
Code  10/06/03 


Pistol  9  mm 
Tank  M60  A3 
Jeep  4x4 
Truck  4x4 


-  3  tons 


Figure  1-14.  Armament  Table  for  Tank  Battalion 
Code  11/08/07 
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